ADDE: Application Development for the Distributed Enterprise

1

• ADDE Application Development for the Distributed
  Enterprise

2
Table of content

• History
• Euromethod background
• Objectives of ADDE
• The ADDE guide
• Macro and micro decisions
• Usage of the guide

3
History

• Euromethod
• Framework for acquisition management and method
  harmonisation
• Client EC
• Supplier Eurogroup Consortium led by Sema Group
• 1991 - 1996
• ISPL
• Next version of Euromethod
• ISPL Consortium
• Supported by ITSMF (ITIL)
• 1997 1998
• ADDE
• Method for Application Development for
  Distributed Enterprise
• Esprit Project
• ADDE Consortium
• 1997 - 1999

4
Euromethod backgroundDecision process
5
Euromethod backgroundDecision process the
rational design process

• By rational application design, we mean a design
  where each design choice is justified by
  arguments based on characteristics of the
  situation of the enterprise within its
  environment business needs, problems, strategy,
  perspectives etc.
• Within a complex environment, it is difficult to
  plan and control the evolution of an organisation
  taking advantage of the ever growing
  opportunities provided by the technologies.
• A moving environment hardly lends itself to the
  explanation by simple and stable theories. The
  way evolution happens is more often the result of
  an emergence phenomenon than a consequence of a
  purely rational design process.
• By emergence of a new organisation, we mean a
  leap from the old stable state of the enterprise
  to a new stable state with its proper goals,
  structures and functioning.
• This leap can be desired or not, triggered or
  not, conscious or not, controlled or not. It
  results from some evolution of the learning
  enterprise and/or its environment. It could be
  induced by the pressure of the market, the
  adoption of new technologies (e.g. groupware,
  Internet), the imitation of the competition, the
  hiring of new staff, etc.
• Emergence may be the result of a self adaptation
  process of an enterprise in response to stimuli
  from the environment (e.g. changes in the market,
  the competition, the technology) this self
  adaptation process may be more or less driven by
  a clear reason.
• Nevertheless, we assume that an evolution process
  - even by emergence- may be guided and at least
  partially controlled by some rational design
  process.
• The advantages of a rational design process are
• A better control of the enterprise evolution
  towards its target.
• An improvement of the maturity of the enterprise
  by learning.

6
Euromethod backgroundSituational approach

• Strategy selection is performed using a flexible
  problem-solving approach called the situational
  approach.
• This aims to improve the effectiveness of the
  acquisition process by tailoring it to each
  problem situation. A tailored acquisition process
  is one that maximises the chances of achieving an
  adaptation successfully, while minimising the
  risks and costs.
• In the situational approach, risk management
  strategy and adaptation plans are adapted to the
  situation, its complexity and uncertainty, and
  contribute to the reduction of risks in the
  situation.
• In a situational approach, the properties of a
  problem situation must be assessed, their likely
  consequences estimated and appropriate strategies
  proposed. These strategies help to reduce the
  risks inherent in the situation.

7
Euromethod backgroundSituational approach
8
Euromethod backgroundThe views
9
Euromethod backgroundThe views
10
Euromethod backgroundThe views
Business activity - what has to be accomplished-
changes relatively slowly. Work practice - who
does what and where they do it- i.e. the mapping
of business activity on to the organisation
structure and roles, generally changes more
frequently than the underlying business activity
as enterprises learn from experience and react to
changing pressure in the market. Information
technologies (IT) - generally change more
dramatically and rapidly than most enterprises
can accommodate. An enterprise, during its
lifetime, has to migrate between technologies. So
it is important to separate the technological
support descriptions from the work practice
descriptions, to minimise the rework required for
technology migration.
11
Euromethod background

• What is not addressed by Euromethod and very
  weakly addressed by methodology aredesign
  decisions
• Design decisions are decisions on whether a new
  (or modified) organisation and/or information
  system is acceptable as it is described.

12
Objectives of ADDE

• To develop guidance for application development
  to support distributed enterprises
• To apply the guidance to a range of real projects
• To develop a repository to support the guidance
• To publish the underlying model of the repository
  for tool vendors

13
Objectives of ADDE

• ADDE is not
• a development methodology
• a development process or lifecycle model
• a procurement or project management method
• an approach for developing business and IT
  strategies
• although it supports parts of the requirements of
  all of these.

14
Objectives of ADDE

• Much of the guidance currently published is more
  about how to use technology than about how to
  support business. This encourages a mind-set of
  How can I use the features of this groupware (or
  intranet, or database, or whatever) technology in
  my organisation. Often, the guidance is defined
  for specific product sets often, it comes from
  the product vendors. This tends to lock
  organisations into these product sets.
• Even worse, product-oriented guidance and the
  desire for rapid development often means that
  requirements are defined only in the implemented
  system - what the technology does, without why it
  is doing it and what business purpose is served..
  Migration to newer, better technology is
  hindered, because it is difficult to abstract the
  requirement from the current implementation
• What is needed, and what ADDE provides, is
  guidance driven by business requirements. What
  is my organisation doing? What kind of IT support
  does it need? What are the best technologies to
  provide it?.

15
Objectives of ADDE

• These issues discussed above apply generally to
  system development, but distributed business has
  some additional concerns
• business activities may be done in different
  locations, with different business rules (e.g. in
  different countries)
• collaborative activity may be spread over several
  locations, and they will need to be coordinated
• responsibilities for tasks may be allocated
  differently in different types of location
• there may be requirements for locations to
  continue to operate (perhaps in degraded mode),
  if they are temporarily unable to communicate
  with other locations
• there may be requirements to replicate IT
  function and partition or replicate data, for
  resilience, security, performance
• IT services might be mapped to different
  technology configurations in different parts of
  the geography

16
Objectives of ADDE

• ADDE is oriented at development of application
  systems. It is assumed that
• the enterprise will have a business strategy - it
  will have decided what business activities are to
  be supported by the applications what
  territories it will operate in who are its
  customers, partners and suppliers and where they
  are located.
• within the enterprise, IT architecture is not
  application-specific. The enterprise will have
  defined (or will define) an IT architecture that
  will support a range of applications - i.e. the
  architecture will be defined outside the ADDE
  development, and the ADDE applications will, in
  general, comply with it.

17
Objectives of ADDE Key features

• Focus on distributed enterprise
• The design is a decision process
• provides a consistent decision process view for
  all roles involved
• rational design each design choice is justified
  based on business arguments
• can be plugged-in existing development methods
  (method independence)
• is not a recipe, but can be adapted to the
  situation (e.g. four quadrants, situation
  analysis)

18
The ADDE guide goal

• To provide guidance for application development
  within distributed enterprise
• identify design decisions to be made
• present advice on making decisions
• describe reports to support decisions
• The guidance does not constitute a comprehensive
  IS development method instead, it may be plugged
  in existing methods and development process models

19
The ADDE guide Structure
20
The ADDE guide characteristics

• The ADDE Guide is a HTML document
• Can also be presented as a text document
• Can be plugged in existing methods
• Can also be used directly by designers
• Can be used without the ADDE repository but it is
  more effective with it

21
Macro and micro decisions

• The design decisions can be taken on various
  levels and can therefore be pictured as a
  decision tree. The decision tree is only a
  hierarchical structure of design decisions, it is
  not a process model. The hierarchical structure
  uses the three ADDE views as a starting point.
• The ADDE views represent a layered architecture
  of the ADDE- model in the sense that layers
  successively build on each other. In other words
  the business determines the requirements for the
  work practice and the work practice determines
  the requirements for the IT-specification.
• Within each ADDE view the decisions are logically
  grouped according to the sequence
• acceptance of requirements constraints
• creation of options or variants
• selection of one option or variant
• The decisions on this level are called macro
  decisions since they are aggregates of micro
  decisions.

22
Macro and micro decisions
23
Macro and micro decisions Micro decisions

• Micro decisions are decisions addressing a
  certain aspect of a certain part of a system (the
  system may be the organisation and/or the ICT
  system).
• Micro decisions form a base of reusable decisions
  which can be used in different contexts, i.e.
  within different macro decisions.
• Micro decisions form the basis of ADDE guidance.
  In a separate annex a catalogue of micro
  decisions is presented. The guidance associated
  with a micro decisions is meant to be applicable
  independent of any method.

24
Macro and micro decisions Micro decisions in
the Business View

• 2.1 How should the business be adapted to
  locations?
• 2.2 What are the business perspectives?
• 2.3 What are the business rules?
• 2.4 What are the critical areas?
• 2.5 What are the dynamic dependencies?
• 2.6 What are the external events?
• 2.7 What are the locations?
• 2.8 What are the measures of performance?
• 2.9 What information is needed to support the
  activity?
• 2.10 What is the activity decomposition?
• 2.11 What is the scope for change?
• 2.12 Where needs the business be executed?
• 2.13 Which business activities should be
  performed?

25
Macro and micro decisions Micro decisions in
the Work Practice View

• 3.18 What communications should be implemented
  between actors?
• 3.19 What communications should be implemented
  between locations?
• 3.20 Is the event ordering consistency important?
• 3.21 What should be the communication quality?
• 3.22 Should communications be synchronous/
  asynchronous?
• 3.23 Should communications be implicit /explicit?
• 3.24 Should communications be formal/ informal?
• 3.25 What should be the security requirements?
• 3.26 What should be the interaction modes?
• 3.27 What co-operation should be implemented
  between actors?
• 3.28 What co-ordination should be implemented
  between actors?
• 3.29 What mechanisms should be in place to ensure
  the co-ordination?
• 3.30 What are the user jobs?
• 3.31 What are the key barriers to change an
  organisation?

• 3.1 Where need the tasks be executed?
• 3.2 How should the tasks be adapted to locations?
• 3.3 What are the tasks of a units of work?
• 3.4 How to satisfy the job demand?
• 3.5 Which actors should be responsible for the
  business activities?
• 3.6 What should be the horizontal division of
  work?
• 3.7 What should be the vertical division of work?
• 3.8 Where should the actors be located?
• 3.9 What are the task requirements?
• 3.10 What should be the task rules?
• 3.11 What should be the organisational events?
• 3.12 How should actors be grouped and structured?
• 3.13 What is the grouping type?
• 3.14 What is the openness of the group?
• 3.15 What communications should be implemented to
  support collaboration?
• 3.16 What communications should be implemented
  between tasks?
• 3.17 What communications should be implemented
  within collaborative tasks?

26
Macro and micro decisions Micro decisions in
the ICT Specification View

• 4.1 What are the constraints by legacy?
• 4.2 Which Tasks should be supported by IT?
• 4.3 How to treat concurrency in the ICT-system?
• 4.4 What are the general constraints to the ICT
  system?
• 4.5 How should IT support the Task?
• 4.6 What should be the information use and
  generation by the tasks?
• 4.7 What should be the computer awareness?
• 4.8 What should be the HCI?
• 4.9 Which logical component should provide a
  given ICT service?
• 4.10 What should be the decomposition of a
  component?
• 4.11 What should be the generalisation of a
  component?
• 4.12 What should be the requirements to a logical
  component?

• 4.13 What data should be used by a logical
  component?
• 4.14 What data should be stored?
• 4.15 Should a set of components be bought,
  rented, reused or developed?
• 4.16 What technology should be used to implement
  a group of components?
• 4.17 How should a component be mapped to the
  architecture?
• 4.18 What should be the distribution of data?
• 4.19 What should be the replication of data?
• 4.20 What should be the distribution of
  components?
• 4.21 What should be the mobility of components?
• 4.22 What should be the characteristics of the
  communications?
• 4.23 What should be the characteristics of the
  nodes?

27
Macro and micro decisions Description of Micro
decisions
28
Macro and micro decisions Example of Micro
decision (1)
29
Macro and micro decisions Example of Micro
decision (2)
30
Macro and micro decisions Example of Micro
decision (3)
31
Macro and micro decisions Example of Micro
decision (4)
32
Macro and micro decisions Example of Micro
decision (5)
33
Macro and micro decisionsMacro decisions

• Macro decisions are logical groupings of
  inter-related micro-decisions
• of the same type which bear on related components
  of the system, e.g.
• decisions on the automation of the various tasks
  constituting a business activity 
• decision on the quality requirements (including
  security) of all the communications of an
  application
• of different types which bear on the same set of
  components, e.g.
• decisions on the communication, co-operation,
  co-ordination and actor structuring for a certain
  part of the organisation
• decisions on the location of business activities,
  the allocation to actors, the tasks
  characteristics for a certain unit of work.

34
Macro and micro decisionsMacro decisions

• A macro-decision provides
• a context in which micro-decisions are made
• a set of inter-related components on which the
  micro-decisions bear
• possibly a set of relationships between the
  micro-decisions (inter-dependencies)
• a consolidation decision which ensures the
  consistency of the individual results of the
  micro-decisions and provides an assessment of the
  overall result.
• The aggregation relationship between macro and
  micro decisions may be represented by a decision
  tree that is a hierarchical structure of design
  decisions. Nodes are macro-decisions while leaves
  are micro-decisions.

35
Macro and micro decisions Macro decisions
36
Macro and micro decisionsMacro decisions

• In a project, decisions have to be adopted to fit
  the situation
• not all macro decisions need to be taken. Some
  might be constraints or others could be taken
  implicit, e.g. rather than creating and selecting
  options one might only create one option.
• macro decisions are often used more than once in
  a project, first at a global level, e.g. ignoring
  some of the related micro decisions, and later a
  second time at a more detailed level.
• in practice macro decisions are often clustered
  in so called decision points and taken at one
  time.
• micro decisions that are aggregated to macro
  decisions may be used in more than one macro
  decision. In that case the macro decision provide
  a context for the micro decision.
• the macro decisions may be applied to various
  scopes, e.g. a macro decision may be taken for
  each unit of work or for each location type or
  project area.
• the decision tree should be viewed as a
  structured pool of macro and micro decisions that
  can be used within the development process of a
  specific method

37
Macro and micro decisions Macro decisions

• Projects are classified into a grid of four
  general cases some limited specific guidance on
  how to sequence the micro decisions can be
  assembled

38
Macro and micro decisions Macro decisions in
the Business View
2.1 Acceptance of Requirements
Constraints 2.1.1 What is the business
scope? 2.1.2 What are the constraints? 2.2
Creation of Business Options 2.2.1 What are the
subsystems? 2.2.2 What is the logical business
model? 2.2.3 What is the dynamical business
model? 2.2.4 How is the location affecting the
business? 2.3 Selection of Business
Options? 2.3.1 How to select business options?
39
Macro and micro decisions Macro decisions in
the Work Practice View
3.1 Decision on requirements and constraints for
work practice 3.1.1 What are the constraints by
Business? 3.1.2 What are the constraints by Work
Practice? 3.1.3 What are the constraints by
ICT-Infrastructure? 3.2 Decision on design
options for work practice 3.2.1 What are the
tasks? 3.2.2 Who are the actors? 3.2.3 What are
the requirements for collaborating groups? 3.2.4
What are the requirements for communication? 3.2.5
How to migrate from the old to the new
system? 3.3 Decision on the selection of options
for work practice 3.3.1 How to select work
practice options?
40
Macro and micro decisions Macro decisions in
the ICT Specification View
4.1 ICT-requirements constraints 4.1.1 What are
the architecture constraints? 4.1.2 What are the
ICT-services? 4.2 Decision on the options for
logical ICT-design 4.2.1 Which set of logical
components should provide the ICT-services? 4.2.2
What should be the logical component
decompositions and generalisations? 4.2.3 What
should be the requirements to the logical
components? 4.2.4 What data should be used by
the logical components? 4.2.5 What data should be
maintained by the application? 4.3 Decision on
the options for Technology Mapping 4.3.1 How to
acquire the logical components? 4.3.2 How do
components fit within the architecture? 4.3.3
Where How should the components be
located? 4.3.4 What capacity upgrade does the
system need? 4.4 Decision on the selection of
options for ICT-design 4.4.1 How to select
ICT-options?
41
Macro and micro decisions Example of Macro
decision (1)
42
Macro and micro decisions Example of Macro
decision (2)

• This decision consists in specifying where the
  various components will be located.
• Each component may be located in one or several
  nodes. The nodes are the ones provided by the
  architecture (current, future, extended
  architecture depending on the case).
• The trade-off for the location of components must
  be assessed with regard to
• Efficiency (response time, processing time,
  required communication bandwidth, storage space
  usage, etc.)
• Reliability some nodes may be more reliable than
  others, local components may be more available
  than remote ones
• Security some nodes are more secure than others
  (e.g. they have a firewall protection) local
  components may be more secure than remote ones.
• Maintainability maintenance can be difficult or
  costly for some nodes.
• Usability operation and administration of
  components may be difficult or costly for some
  nodes.
• In case of replication of a component, the
  consistency between the copies must be ensured.
  The strategy and cost for maintaining consistency
  must be decided.
• If the technology allows for it, the mobility of
  the components may be considered as an option.
  This is the case for Java applets or mobile
  agents.
• When two or more distribution scenarios satisfy
  the requirements, they can be compared against
  their costs. These costs cover
• Technology and system acquisition costs
  (hardware, software, communications, environment)
• Development costs (specification, construction,
  installation for computerised systems training
  for human beings)
• Operation costs (human beings, communications,
  computers, environment, insurance, assistance,
  etc.)
• Maintenance and adaptation costs
• Usage costs
• Provisions for risks such as security violation
  or system breakdown.

43
Macro and micro decisions Example of Macro
decision (3)

• This decision is complex because
• A lot of factors must be taken into account (see
  above)
• The optimal location of one component depends on
  the location of business actors using it,
  accessed data and other components using it or
  used by it.
• The decision will then depend on the solution of
  a complex optimisation problem. But sheer
  computations might not represent the reality with
  sufficient accuracy because it is difficult to
  take into account the optimisation algorithms
  provided by the various technologies involved
  (DBMS, OS, DCE, middleware, etc.). The used
  technologies and the architecture play an
  important role in that decision. It is thus
  useful to perform benchmarks or to plan for
  tuning the system after its installation.
• To facilitate the optimisation, several
  configurations should be generated. This can be
  done using the guidance provided within the
  different micro-decisions. If not optimal, these
  configurations would be fair enough for
  implementation. Computations, benchmarks and
  tuning could then be used to compare and optimise
  those configurations.
• Normally several options should be kept for
  assessment in the Decision on the selection of
  options for ICT-design. Each option should be
  qualified with the degree to which the various
  cost and quality requirements are satisfied.
• The decision on the mapping of components to the
  architecture should be revisited at this point,
  because this mapping could be different from one
  location to another one.
• The micro-decisions make a distinction between
  stored data, i.e. components managing stored
  data, and the other components processing some
  other functions.
• The decision on mobility is relevant when the
  technology allows for component mobility.
• In any case, as explained above, those individual
  decisions are intertwined and their consolidation
  should be checked for consistency, e.g. the
  economy of function distribution will depend on
  data distribution and vice-versa.

44
Usage of the guide
45
Usage of the guide Acquisition manager

• DEFINING/PLANNING APPLICATION DEVELOPMENT
• Defining the application development
• Understanding the business strategy
• Analysing the requirements to the application
• Analysing costs and benefits of development
• Analysing the risks of the application
  development
• Planning the application development
• Determining the overall development plan
• Elaborating the risk management strategy
• Delivery plans and ADDE decision support strategy

46
Usage of the guide Acquisition managerA
delivery plan
47
Usage of the guide Project manager

• Makes a project plan which satisfies the
  requirements from the delivery plan
• derives a plan from method process model
• defines tasks
• allocates tasks to his team
• maps ADDE macro-decisions to the tasks
• maps other macro-decisions to the tasks
• maps ADDE reports to the work products
• maps other reports to the work products

48
Usage of the guide Project manager
49
Usage of the guide Project managerMapping ADDE
components to project plan
50
Usage of the guide DesignerDesigning the
application
51
Usage of the guide Methodologist
52
Usage of the guide Methodologist

• Fitting ADDE guidance into in-house development
  practice has four aspects
• where in the development process ADDEs decisions
  will fit, from both technical and project
  management perspectives.
• what other decisions are affected by ADDE
  decisions - how results of ADDE decisions are
  incorporated into major project decisions
• how to construct the ADDE decision structure in
  project planning - customisation of the general
  guidance provided by ADDE
• plugging gaps - are there inputs that ADDE
  expects that are not addressed by current
  practice?

53
Usage of the guide Method/Tool vendor