Marcel FrancksonPage 1 ADDE: Application Development for the Distributed Enterprise

Marcel Franckson Page 1Application Development for the Distributed Enterprise

ADDE: Application Development for the

Distributed Enterprise


Table of content

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


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


Euromethod background:Decision process

Plan Report

Decisions

goals

SWATAnalysis

Strategy

DecisionPointSequence

Tendering

workpackages

resources

budget

Monitoring

Project Decisions Contract Decisions

Level

Business

Work Practice

IT-Specification

View

macro&

micro

Design Decisions

DeliveryPlan


Euromethod background:Decision 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.


Euromethod background:Situational 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.

Problem situation(need for an

adaptation of aninformation system)

Risk managementstrategy

determines

is tailored to


Euromethod background:Situational approach

Legendupdates

used by

requests for updateAdministr. completion

Preparation of request for proposal

Response preparation

Supplier selection

Contract preparation

Decision point execution

Tendering

Delivery planning techniques

Delivery Plan

Acquisition Initiation

Procurement

Decision points plannin

g

Descriptionof

deliverables

Design of

delivery strategyContract

monitoring

Contract completion

Description of

services

Acquisition Completion

Situation and risk

analysis


Euromethod background:The views

Specifying deliverables 15© ISPL Consortium

The information system views

Processes

Actors

use

perform

Information system

Information resource

use

defines representation of



supports

Computer system

Work practice view

Business process view

Information system views

Business information view



Specifying deliverables 17© ISPL Consortium

The Computer System Views

represents automated

part of

represents structuring of

Work practice view

Business process view

Business information view

Information system views

Computer system

represents implementation

and distribution of

represents automated

part of

Computer system architecture view

Computer system function view

Computer system data view

Computer system views



Business Activitychanges relatively slowly

Work Practicechanges as the enterprise adapts

ICT (Technology)changes occur frequently

Technologicalrequirements

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.


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.


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


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.


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?“.


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


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.


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)


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


The ADDE guide: Structure

Macro Decisions /

Business Process

IT-Specification

Work Practice

View

ViewView

Improve Current WP

Decision Trees

ADDE Reports

Business Process

IT-Specification

Work Practice

View

ViewView

documents decision

Micro Decisions

Business Process

IT-Specification

Work Practice

View

ViewView

Design DecisionProcess

Define & Planthe Application Development

• .............• .............•

••

• .............

needed as input

Repository

ADDE Model / Concept Catalogue

Business Process

IT-Specification

Work Practice

View

ViewView

content defined by

decided characteristics

EU Rent / Case Study

Chapter 5

Annex B

Annex C

Chapter 4

Annex A

Annex D


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


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.


Macro and micro decisions

Business

Decision Tree

Work Practice

Design of Options forWork Practice

Acceptance of Require-ments & Constraints forWork Practice

Selection of Optionsfor Work Practice

IT-specification

IT-requirements &constraints

Selection ofOptions for IT

Options for Technology Mapping

Creation of BusinessOptions

Acceptance of BusinessRequirements &Constraints

Selection of BusinessOptions

Logical IT-Design Options


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.


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?


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

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?

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?


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?


Macro and micro decisions: Description of Micro decisions

Decision Name of the decision such as listed in the previous section.What is decided? Characteristics of the system that are decided by fixing their value. A characteristic refers

to one or more concepts of the ADDE model.Work product Input work products that provide the necessary information (input characteristics) to

allow to make a decision.Work products are defined as SQL-reports and could be provided by the ADDErepository.

Guidance Heuristics which help the designer to make the decision. Normally, the heuristics shouldrelate What is decided?’ with the content of the input work products.

Example The decision may be explained by an example from EU-Rent giving the kind of optionsone has.

Sub-decisions When the decision contains sub-decisions, they are mentioned here.Sub-decisions are described in a similar form.


Macro and micro decisions: Example of Micro decision (1)

Decision What should be the distribution of components?

What is decided?

The location of components performing functions other than data management

ADDE Reports Data needed by components

Stored data

Logical component requirements

Logical components

ICT services



The distribution of the components depends on the following requirements:

Efficiency:

Response time: The aspect of efficiency that is the most important is the response time. The requirements for the response time requested from components derive from the efficiency requirements of the ICT services (services to the business actors). A response time can actually be associated to each pair (service, service client). The client may be another component or a business actor. Each of those response times should comply with its requirements. One could also optimise the „Average response time“ provided by the component for each service to each client. The „Average response time“ is equal to: SUM for all services and all clients (PRODUCT (Frequency of use of the service by the client, Response time of the service for that client)). A component close to its usage location will improve the response time since it saves communication time. On the other hand, a component that consumes a lot of resources (CPU, memory, storage space, etc.) will be executed more efficiently by those nodes owning those resources in sufficient quantity. When the same node cannot provide these two characteristics, there is a trade-off between the saving of communication time and the saving of processing time. Several types of components should be distinguished:

HCI components: an HCI component provides ICT services to business actors. An interactive, or a real-time HCI component undergo many interactions with its users. Locating the HCI component close to its user, e.g. on its desktop, would normally improve the response time. When there are several users of that component, it would then be replicated on the nodes closest to its users.

Components executing heavy processes: these components provide services at a level of automation such as simulating, executing processes, proposing decisions and complex checking. These components use a lot of processing resources and would then be well located on nodes able to provide those resources. If several nodes are candidates, then the closest to its users (business actors or other components) could be selected. Replication on several nodes can also improve response time, especially if load balancing is provided by the used technology.

Components accessing a lot of data: these components are best located close to the data they access. If data is replicated the components would be replicated too.

Components providing services to a set of components located in one node: these components are best located on that node provided it owns the necessary resources.

If a component belongs to more than one class, than the response time should be calculated for the various potential locations, taking into account the processing time and the communication time. An alternative could be to decompose the component into two or more components; this would give the opportunity to locate the sub-components in different places. The selection decision is however constrained by the other requirements.



Resource usage: the efficiency regarding resource usage is often better in central systems than in distributed ones, especially for expensive resources able to process high volumes (e.g. high volume printers, megacomputers). The redundancy of components requiring those resources in several locations is not cost effective in many cases, because resources need to be multiplied without being fully exploited.

Reliability: Normally, components close to the usage location will improve the reliability since they save communication failures; when the network is down in a centralised system, then it is impossible for users to progress work at any location; but in a distributed system, there may still be processing that can be carried out locally. This general rule may however be contradicted for certain architectures; e.g. a very reliable system in one node and very reliable communications could provide a better level of reliability than less reliable local systems. Replication of a component on several nodes will always increase reliability, but this would be detrimental to the cost of the system, maintainability and usability. The requirements for the reliability of services provided by components derive from the reliability requirements of the ICT services. For each configuration of component distribution, the reliability of each service to each client must be assessed. On this basis, it can be decided to discard certain configurations even if their efficiency is good.



Security: It takes three aspects:

Integrity of the component: preventing unauthorised modification to or destruction of the component,

Confidentiality of the component: preventing unauthorised reading or knowledge of the component,

Availability: ensuring that the component is accessible to authorised users. Normally, a component close to the usage location should improve the security since it mitigates the threats on the communications. This general rule may however be contradicted for certain architectures; e.g. a very secure node protected by firewalls and very secure communications, using message encryption, could provide a better level of security than less secure local systems. To be more precise, one needs to consider the three aspects of security:

Integrity is better ensured when the component is located in a well protected node. Protected communications are needed to prevent intruders from tampering with the transmitted data.

Confidentiality is better ensured when the component is located in a well protected node. Protected communications are needed to prevent intruders from tapping the transmitted data. Confidentiality could also be provided by a local node isolated from external communications.

Availability is always better when the component is local. The requirements for the security of components derive from the security requirements of the ICT services. For each configuration of component distribution, the security of each component for each service and each client must be assessed. On this basis, it can be decided to discard certain configurations even if their efficiency is good. As for data, the following factors must be considered when implementing a security policy and comparing distribution configurations:

Privileges: the system must be able to identify who is authorised to do what.

Identification and authentication: the system should challenge users to prove their identity with techniques such as passwords, voice prints and codes.

Correctness: security enforcement should not fail to mediate each access correctly and should not be bypassed or tampered with.

Audit: the system should produce audit trails and logs of security related events.



Usability: Usability is an important issue for system administrators. Depending on the tools available within the architecture, system administrators can manage systems from a remote location or not. If not, they must be located close to the system. The distribution of components will then request the provision of system administrators for all locations, either on-site or by means of a travelling team; this will increase the costs.

Maintainability: A distributed system is usually more difficult to maintain than a non-distributed one insofar as it requires installations in several sites. This will entail additional costs. The maintenance of replicated components is even more difficult insofar as it requires managing configurations and consistency of the copies.

Adaptability: A distributed system can be adapted more easily to local requirements; on the other hand the adaptation of the system for all locations is more complex when it is distributed.

Cost of the technology: Distributed systems are usually more expensive than non-distributed ones, because it requires more sophisticated technologies or additional developments.


Macro and micro decisions:Macro 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.



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.


Macro and micro decisions: Macro decisions

Decision onwork practiceareas ofimprovement

Decision on the global work practices

Decision onrequirementsand constraintsfor workpractices

Decision onthe globaldesignoptions forworkpractices

Decision onthe selectionof optionsfor workpractices

What are the location constraints?

How shall the business be adapted to the locations?

What are the tasks?

Who are the tasks performers?

What are the requirements for collaborating groups?

What are the requirements for communications?

What are the IT services?



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


Macro and micro decisions: Macro decisions

1 design of a new enterprise

Fresh start with no legacy system and no constraints by existing ICT or Organisation

2 new business activity for existing organisation.

Extending the existing Business and Information System

3 improvement of current work practices

Small changes in work practice usually done by any learning system

4 redesign current work practice

Radical change of work practice and business, often triggered by changes in business and made possible by new technology

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


Macro and micro decisions: Macro decisions in the Business View

2.1 Acceptance of Requirements & Constraints2.1.1 What is the business scope?2.1.2 What are the constraints?2.2 Creation of Business Options2.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?


Macro and micro decisions: Macro decisions in the Work Practice View

3.1 Decision on requirements and constraints for work practice3.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 practice3.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 practice3.3.1 How to select work practice options?


Macro and micro decisions: Macro decisions in the ICT Specification View

4.1 ICT-requirements & constraints4.1.1 What are the architecture constraints?4.1.2 What are the ICT-services?4.2 Decision on the options for logical ICT-design4.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 Mapping4.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-design4.4.1 How to select ICT-options?


Macro and micro decisions: Example of Macro decision (1)

Name Where & How should the components be located?

Goal Locate the components Determine whether the components are replicated and how replicates are

managed Determine whether components are mobile

Result Location of components, Mapping of components to architecture, implementation technology, acquisition mode, data needed by components, stored data, logical component requirements, set of logical components, ICT-services

List of Micro Decisions

What should be the distribution of data? What should be the replication of data? What should be the distribution of components? What should be the mobility of components?

ADDE Reports Within ADDE:

Location Constraints

Outside ADDE: Implementation technology, acquisition mode, logical component requirements vs. real qualification



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.



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.


Usage of the guide

AcquisitionManager

Project Manager Analysts &Designers

Methodologist Method & ToolVendors

.. responsible forsystem acquisition

..plans & managesprojects that use

ADDE

.. proposes designotpions

..fit ADDE intoApplicationDevelopment

.. may choose tosupport ADDE


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


Usage of the guide: Acquisition managerA delivery plan

Obelix project Jan Feb March April May June July Aug Sept Oct Nov Dec

Decision points1. Approval of business scope

2. Approval of global work practice specification

3. Approval of IT architecture

4. Approval of detailed work practice specification

5. Approval of IT specification

6. Approval of technology mapping

Legend: decision point to be executed

executed decision point

delayed decision point

decision point to be re-executed


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


Usage of the guide: Project manager

Micro-decision

(+ supporting guidance)

Micro-decision


Micro-decision


Micro-decision


Micro-decision(+ supporting guidance)

ADDE reportssupporting

Micro Decisions

Project-specific macro-decision structure

Projectcharacteristics

adapted ADDE guidance

Project Plans

Defined within ADDE

Organisation-specific Application Development

Figure 0-1: Incorporating ADDE elements into project plans


Usage of the guide: Project managerMapping ADDE components to project plan

Design new workpractices options

Assess options andproposes selection

Work product 2

Work product 3

Work product 1

Method process modelor

project plan

ADDEcomponents

uses

Mapping

Decision onglobal designoptions forthe workpractices

ADDE report

Decision onselection ofoptions forthe workpractices

ADDEreport

uses

Figure 0-1: Mapping of ADDE components tomethod process models or project plans


Usage of the guide: DesignerDesigning the application

ADDE Repository

Stores components ofmethod work products

ADDERepository

Products

Specific developmentpractice,methodology,tools, etc.

ADDE Reportof

Repository

Repository Interface

components

Design

Decisions

microdecision

macrodecision


Usage of the guide: Methodologist

Organisation-specific Application Development

Adapted ADDE Guidance

ADDE Guide

RepositoryDevelopment Tools

ADDE Reports

Tool Interface

to feed repository


Usage of the guide: Methodologist

Fitting ADDE guidance into in-house development practice has four aspects:

where in the development process ADDE’s 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?


Usage of the guide: Method/Tool vendor

Application Development MethodologyDecisions &SupportingGuidance

Reports

Input Information

• Adopted ADDE Guideance

• Adopted ADDE Reports

• Modified Work Products

ADDE Guide

ADDE Model

Documents

Marcel FrancksonPage 1 ADDE: Application Development for the Distributed Enterprise