Architecture Development Method (ADM)

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.co.uk in whichever social media you use.

TOGAF® ArchiMate® are registered trademarks of The Open Group.

TOGAF is the most popular public domain enterprise architecture framework.

Since it is voluminous, multi-authored and not an easy read; the Avancier web site hosts papers to help you understand it.

Beware that most TOGAF authors take it for granted you know architecture description techniques already.

TOGAF is a specific transformation management framework

If you want to understand enterprise architecture in general and specific architecting practices, then go to avancier.website.

Abstract

The strength of TOGAF does not lie in architecture definition - it tells you surprisingly little about that - it is rather a management framework for architecture work.

It promotes the idea of architecture-led planning, rather than management-led architecture.

People use it to record a “baseline architecture”, develop a "target architecture" to meet requirements for change, then plan and govern the transformation of systems from the baseline to the target.

The core of TOGAF is the ADM, a ten-phase cyclical process, a generic method that can be adapted for any kind of transformation or change programme that involves information systems.

There is a continuous phase, not listed below, covering management of the requirements.

The table below illuminates the ADM phases with process names used in Avancier Methods.

	Architecture Development Method (ADM)	Avancier Methods
ESTABLISH CAPABILITY	Preliminary Phase Phase A: Architecture Vision	Establish capability Establish the context Scope the endeavour Get vision approved
DEVELOP	Phase B: Business Architecture Phase C: Information Systems Architecture Data Architecture + Applications Architecture Phase D: Technology Architecture	Understand the baseline Review results of initiation Clarify NFRs Design the target
PLAN	Phase E Opportunities and Solutions Phase F: Migration Planning	Select suppliers Plot migration path Review business case Plan delivery
GOVERN	Phase G: Implementation Governance Phase H: Architecture Change Management	Hand over to delivery Govern delivery Monitor portfolios Respond to operational change

Contents list

The Architecture Capability Iteration

Preliminary Phase

Phase A: Architecture Vision

The Architecture Development Iteration (B to F)

Phase B: Business Architecture

Phase C: Information System Architecture

Phase D: Technology Architecture

The Transition Planning Iteration (E and F)

Phase E: Opportunities and Solutions

Phase F: Migration Planning

The Architecture Governance Iteration (G and H)

Phase G: [Architecture] Implementation Governance

Phase H: Architecture Change Management

Requirements Management Phase

Do we use ADM for solution architecture as well as enterprise architecture?

The Architecture Capability Iteration

The Preliminary Phase and Phase A (Architecture Vision) are about getting started.

Remember that the ADM is not the only management process you need:

"The ADM... is complementary to... standard program management processes, such as those for authorization, risk management, business planning and budgeting, development planning, systems development, and procurement."

Preliminary Phase

An enterprise architecture cycle should help an organisation to rationalise its systems and coordinate its projects.

It should help an organisation to develop and implement a cross-organisational strategy.

This effort requires sponsorship and support from the top-level “directors” of the organisation.

The preliminary phase is designed to help an enterprise architecture team establish their capability and their place in the enterprise.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Preliminary	Determine capability, Establish capability	Organisational model for EA
	Identify/tailor Frameworks	Tailored Architecture Framework
	Define Architecture Principles	Architecture Principles	Architecture Principles Catalogue	Architecture Principles
		Request For Architecture Work

"most organizations have a method for the development of solutions... The Phase therefore involves doing any necessary work to adapt the ADM to define an organization-specific framework"

Deliverables are discussed below.

Deliverable	Notes
Architecture Repository	As far as it has been completed by previous architecture definition exercises.
Organizational Model for Enterprise Architecture	The EA team, its place in the organisation and its governance structures. Governance requires three things: People: a governance organization Processes for governance Products: governance artifacts: including architecture contracts and checklists.
Tailored Architecture Framework	You must customize TOGAF to align with methods for · Business planning · Programme/project management. · IT governance (COBIT), · IT service management (ITIL) · Methods used by suppliers.
Business Principles, Business Goals, and Business Drivers	Gathered from the business and perhaps restated.
Architecture Principles	Principles help architects to steer architecture development in ways that suit the business goals, strengths and weaknesses. A principle should be simple, brief, stable guidance. It should be choice reducer/simplifier and conflict reducer/resolver. An enterprise typically has around 20 architecture principles. TOGAF doesn't prescribe your architecture principles. It gives you 21 (ex USAF) principles to start from. It gives you a template for defining principles (Name, Description, Rationale, Implications). Conflicts between principles must be made explicit and the trade-offs explained.
Request for Architecture Work	The document that gives the team direction to produce and Architecture Vision

Phase A: Architecture Vision

This phase starts with a Request for Architecture Work and ends with an approved Statement of Architecture Work.

The request usually emerges from a significant change in the business or its management structure.

The phase engages stakeholders and gets their approval for the Statement of Architecture Work that will carry the architecture team through an architecture project from phases B to F (the “Architecture Development Iteration”.).

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Architecture Vision	Develop Architecture Vision Approval of Statement Of Architecture Work	Architecture Vision (ADD v0.1) Communication Plan Statement Of Architecture Work Capability Assessments	Value Chain Diagram Stakeholder Map Matrix Solution Concept Diagram	Business Scenarios Stakeholder Management Business Transformation Readiness Ass. Risk Analysis

Deliverables are discussed below.

Deliverable	Notes
Architecture Vision	The architecture vision is, or is aligned with, architecture definition v0.1. TOGAF recommends the architecture vision is described using business scenarios
Communications Plan	You plan how you will keep all stakeholders on board.
Statement of Architecture Work	An architecture project initiation document: defines the focus and timescales of the ADM cycle to follow. Clarifies scope and get stakeholders’ approval for the architecture project.
Capability Assessment	Assesses the maturity of the business, IT and architecture functions Considering any factor that influences their ability and readiness to change as envisioned.

FAQS

Q) Why does TOGAF devote so much space to Business Scenarios?

A) Because an Open Group’s driver is Business-IT alignment.

TOGAF 7 authors employed "Business Scenarios" as a means of capturing business requirements and relating IT to it.

Q) Why aren't other analysis and design techniques (e.g. requirements cataloguing, data modelling) described?

A) Other techniques are taken for granted.

Q) Why are the Open Group example Business Scenarios so dodgy?

A) Probably because nobody will submit real examples for publication.

The examples do successfully illustrate how the Business Scenarios template provides a good structure for presenting generic technology architecture descriptions.

Q) Surely Business Scenarios is solution-level technique?

A) That is often true. However, some businesses are based on one or a very few end-to-end business processes.

Q) Should procurement specialists be engaged in phase A?

A) Yes, they are stakeholders and their policies may constrain technology choice.

Note however that a raison d’être of the Open Group and TOGAF is to promote vendor/technology-neutral specifications and decisions.

And ADM promotes three sequences: Business before Technology; Logical before Physical; High-level before Detail.

So procurement decisions are postponed until a complete logical rationale has been documented.

The Architecture Development Iteration (B to F)

Phases B, C and D, repeat the same process for each of the four architecture domains.

They produce the logical Architecture Definition Document - which contains artifacts discussed in the Content Framework paper.

They produce simple roadmaps, listing work to cross the gaps between the baseline and target architectures.

Phase B: Business Architecture

Inputs: everything produced so far.

Outputs: business architecture models and report. The start of a business change road map. Refined versions of the inputs.

Process: the generic process repeated in phases B, C and D.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Business Architecture	Determine target architecture Identify roadmap components	Architecture Definition Document Road Map Components Architecture Requirements Specification	Organisation Decomposition Structure Business Function Decomposition Hierarchy Business Process Flow Diagrams Business Role Catalogue	Architecture Patterns Gap Analysis

FAQS

Q) Who does the work to define business goals, organisations, functions, processes, roles?

A) Usually people called systems analysts, business analysts, business management consultants or business architects.

These people must be engaged closely with the enterprise architects, and ideally work in the same team.

Phase C: Information System Architecture

Data Architecture

Inputs: everything produced so far.

Outputs: data architecture models and report. The start of a data change road map. Refined versions of the inputs.

Process: the generic process repeated in phases B, C and D.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
IS (Data) Architecture	Determine target architecture Identify roadmap components	Architecture Definition Document Road Map Components Architecture Requirements Specification	Data Entity – Business Function Matrix Conceptual Data Diagram Logical Data Diagram Data Dissemination Diagram	Architecture Patterns Gap Analysis

Applications Architecture

Inputs: everything produced so far.

Outputs: applications architecture models and report. The start of an applications change road map. Refined versions of the inputs.

Process: the generic process repeated in phases B, C and D.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
IS (Apps) Architecture	Determine target architecture Identify roadmap components	Architecture Definition Document Road Map Components Architecture Requirements Specification	App Portfolio Catalogue App – Business Function Matrix Apps Communication Diagram Process App Realisation Diagram	Architecture Patterns Gap Analysis

FAQS

Q) How detailed should an applications architecture description be?

A) Not at all detailed. TOGAF’s enterprise architecture is “considerably abstracted from solution architectrure”.

The architecture building blocks are coarse-grained and logical specifications.

Phase D: Technology Architecture

Inputs: everything produced so far.

Outputs: technology architecture models and report. The start of a technology change road map. Refined versions of the inputs.

Process: as generic process repeated in phases B, C and D.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Technology Architecture	Determine target architecture Identify roadmap components	Architecture Definition Document Road Map Components Architecture Requirements Specification	Technology Portfolio Catalogue Technical Reference Model (TRM) App – Technology Matrix Networked Computing Hardware Diagram Communications Engineering Diagram	Architecture Patterns Gap Analysis

This phase (because it has been generalised to follow the same process as phases B and C) as lost the guidance that was in TOGAF 7 and 8.

Admittedly, the old process used to be very badly written – but it needed rewriting rather than throwing away.

FAQS

Q) When does specification of a required building block become a vendor-product-version-specific?

A) Remember the Clinger-Cohen act (and related OMB guidance) guided IT directors and CIOs to:

• Relate IT procurement to business improvement:
• Justify IT procurement decisions according to a documented rationale
• Use logical (vendor/technology neutral) specifications as far as is possible into the procurement process
• Maintain logical specifications or baseline technologies, so as to facilitate portability.

So, ADM encourages vendor-product-version-specific decisions to be made at the latest reasonable point.

Potential solutions in phase E. Actual solutions in phase G.

Though it also allows that technology choices may be constrained by standards or policies, perhaps from a previous cycle of ADM.

Q) Is a newly-required building block purchased in phase D?

A) No, because a) different solution building blocks (opportunities) may be identified and selected during phases E and G.

And b) solution building block acquisition is best timed to occur in the sequence required by the migration path defined in phase F.

The procurement department are best engaged to procure solution building blocks in phase G.

The Transition Planning Iteration (E and F)

Phase F starts: "Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change."

Phase G starts: "in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens."

TOGAF says enough that you know what needs to be done by way of planning, governance, change and requirements management. It does not set out to compete with established management methods.

It expects your PMO and ITSM organisations to be using MSP, PRINCE2 , PMI, ITIL or whatever.

It expects you to integrate the activities of phases E to H into those methods.

Phase E: Opportunities and Solutions

This phase is about identifying Solutions that will realise the logical architecture definition and organising the migration into a series of Transition Architectures

This is a complex and somewhat messy process.

The idea is for the architect identify potential solution building blocks, then come up with rational road map.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Opps & Solutions	Generate Initial Roadmap Identify Transitions	Architecture Road Map (Transitions, WPs) Implementation & Migration Plan (strategy) Architecture Requirements Specification Capability Assessments	Gaps Solutions & Dependencies Matrix Implementation Factor Assessment & Deduction Matrix	Migration Planning Interoperability requirements

The process involves:

• Consolidating gap analysis results from phases B to D into work packages.
• Assessing the priorities and dependencies between the various work packages.
• Classifying work packages as new development, purchase opportunity, or reuse of existing system.
• Generating a road map and overall implementation and migration strategy.

Phase F: Migration Planning

This phase is about detailed planning of the work (in coordination with Programme and Project Managers) to implement a migration from baseline architecture to target architecture.

The process engages programme and project managers to produce a detail migration plan, containing projects that move the enterprise from the baseline architecture to the target architecture.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Migration Planning	Complete Roadmap & Migration Plan Coordinate Plan with Change Management Ensure cost & value of work packages understood	Implementation & Migration Plan Implementation Governance Model Change Requests	Architecture Definition Increments Table Transition Architecture State Evolution Table Architecture Updates	Migration Planning

The process involves:

• Helping managers prioritise by defining the value and risk of each thing to be done.
• Estimating resource requirements and availability
• Performing cost / benefit assessment of the various migration projects
• Performing risk assessment
• Documenting a detailed Migration Plan in which work is costed, resourced and timetabled.

The Architecture Governance Iteration (G and H)

Phase G Implementation Governance is about governing to ensure the architecture is used in and aligned with what implementation projects produce (in coordination with Programne and Project Managers).

Phase H Architecture Change Management is about governing to ensure the architecture is used in and aligned with changes to operational systems (in coordination with IT Services Management).

Phase G: [Architecture] Implementation Governance

Implementation is composed of projects led by the programme/project management office.

This phase is called Implementation Governance because phase G describes only the role the enterprise architect plays in implementation.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Implementation Governance	Ensure conformance of Implementation Govern solution & change requests	Architecture (Development) Contracts Compliance Assessments Change Requests	Architecture-Compliant Solutions Architecture Updates

Governance ensures projects and changes stick to enterprise architecture-level principles, standards and high-level designs.

Governance needs organisation, processes and artifacts.

Architecture Contracts define what enterprise architects expect of projects.

Governance appears three times in ADM

• Phase B to F. These are governed according to the Statement of Architecture Work produced in phase A.
• Phase G: Implementation governance is governed according architecture contracts and project recommendations. These define the responsibilities of solution/project architects with respect to the enterprise architecture.
• Phase H: Business units that may build or install new systems are governed according to an architecture contract that constraints them to conform to the EA baseline established at the end of Phase G.

Governance processes must be based on-going compliance reviews to

• check the contract is being applied,
• grant dispensations and
• learn from feedback.

Remember that governance, change management and requirements management processes are closely related.

The next and last two TOGAF phases are about identifying and managing the requirements that drive an enterprise architecture development cycle.

Phase H: Architecture Change Management

TOGAF tells you to establish a process for the management of changes to the new enterprise architecture baseline that is achieved with completion of phase G.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Arch. Change Management	Maintain architecture lifecycle Execute governance Ensure capability meets requirements	Architecture (Operational) Contracts Change Requests Request For Architecture Work	Architecture Updates

Really, this last phase should be in place from day 1, otherwise the enterprise architecture development team may be kept in the dark about significant business or technical changes affecting the enterprise (this has been known to happen).

TOGAF’s chapter on Architecture Change Management starts as below [with two editorial inserts].

"The goal of an architecture change management process is to ensure that the architecture achieves its original target business value.

This includes managing changes to the architecture in a cohesive and architected way.

This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment.

When changes [to the architecture description] are identified, change management will determine whether to formally initiate a new architecture evolution cycle.

Additionally, the architecture change management process aims to establish and support the implemented enterprise architecture [the operational systems] as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment.

Monitoring business growth and decline is a critical aspect of this phase.

Usage of the enterprise architecture is the most important part of the architecture development cycle.

All too often the business has been left with an enterprise architecture that works for the organization of yesterday but may not give back sufficient capability to meet the needs of the enterprise of today and tomorrow.

In many cases the architecture continues to fit, but the solutions underlying them may not, and some changes are required.

The enterprise architect needs to be aware of these change requirements and considers this an essential part of constant renewal of the architecture." 

Here architecture not = system. This is about alignment of changes to architecture descriptions with changes to operational systems.

The term architecture refers to architecture descriptions found in TOGAF's architecture definition, architecture continuum and architecture repository. 

Business, political and technology changes are inevitable. Change management is necessary, and it requires three things:

• A change management organization
• Change management processes
• Change artifacts: change descriptions and chance impact reports.

The change management process should include,

• Identify change (ongoing monitoring of technology changes and business changes)
• Record change,
• Assess impact of change,
• Determine action,
• Develop a position to act
• Do change action.

TOGAF speaks of change management at two levels: changed that trigger a new cycle of ADM, changes handled within a cycle of ADM.

There must be an Architecture Board (or other governing council) to decide on handling technology and business changes.

Remember that governance, change management and requirements management processes are closely related.

TOGAF is not a quality management system contained detailed management processes.

Phase H is not about managing all changes to everything – only those changes affecting the enterprise architecture.

FAQS

Q) Is this change management as in ITIL?

A) No. All implemented systems should be placed under change management, which usually comes under IT service management, and is in the territory of ITIL.

The enterprise architects' job is to ensure a systems change management is in place and that enterprise architects are engaged when appropriate.

This implies one of the following:

• The architecture board has a representative on the IT change board, or
• The IT change board reports changes affecting the enterprise architecture to the architecture board, or
• The architecture and IT governance organisations and processes are merged.

Q) How do we correct past irrational and costly technology procurement decisions?

A) Establish a change management process. Establish the authority of the architecture board. Identify a better technology or solution and treat it as an event triggering a change request.

Requirements Management Phase

This on-going phase manages the Architecture Requirements Specification.

Phase	Objectives	Notable deliverables	Notable artifacts and tables	Techniques
Requirements Management	Sustain RM process Manage architecture requirements Ensure architecture requirements available	Architecture Requirements Specification Requirements Impact Statements	Gap Analysis Results Implementation & Operations Guidelines

“Typical contents of an Architecture Requirements Specification are:

• Success measures [for a cycle of ADM]
• Architecture requirements [for business, data, applications and technology]
• Business service contracts [after phase B]
• Application service contracts [after phase C]
• Implementation guidelines [for phase G]
• Implementation specifications [for phase G]
• Implementation standards [for phase G]
• Interoperability requirements
• Constraints
• Assumptions”

TOGAF does not make clear how this requirements specification relates to the requirements repository.

“The requirements repository contains the current requirements for the Target Architecture.”

Some TOGAF gurus say there is:

· one Architecture Requirements Specification for each cycle of ADM.

· one requirements repository for the whole enterprise, which is subdivided for each cycle of ADM.

The requirements repository could include business goals, business objectives, policies, principles, rules, guidelines, standards.

The Architecture Requirements Specification is updated during each phase, and may be updated then with Gap Analysis results (not mentioned in the contents list above).

The requirements management phase in TOGAF is ongoing throughout the ADM cycle.

It can be viewed as the change management process for architecture description, whereas phase H is the change management process for the implemented systems.

Requirements management is necessary, and it requires three things:

• A requirements management organization
• A requirements management processes
• Requirements artifacts: requirements statements and requirements impact reports.

TOGAF tells you to establish a process for the capture and management of requirements. The process must

• identify requirements for enterprise architecture (usually as a result of change management)
• store the requirements in a requirement repository, and
• produce requirements impact statement that identifies the phases of the ADM that need to be revisited (or rather, the deliverables of those phases).

TOGAF outlines a ten step process for requirements management..

• Steps 1 to 3 are requirements capture. The main output is a requirements catalogue or repository.
• Steps 4 to 10 are effectively change management. The main outputs are requirements impact statements.
• Steps 2,3,5,8 are done within requirements management, the rest take place in other ADM phases.

Requirements go through iterations until the final version includes the full implications of the requirements (e.g., costs, timescales, business metrics) on the architecture development.

Remember that governance, change management and requirements management processes are closely related.

FAQS

Q) Why is the RM process so convoluted?

A) Because it spans three time periods

• requirements capture up to the point they are base-lined.
• changes to requirements during architecture development: phases A to G.
• changes to requirements after systems implementation: phase H.

And two levels of impact analysis:

• In Requirements Management, which phases are impacted?
• Within a phase, which deliverables of this phase are impacted?

Q) How can we revisit a phase that has been completed and signed off?

A) You can't. You can however revisit the deliverables of an earlier phase.

Do we use ADM for solution architecture as well as enterprise architecture?

ADM is primarily written for abstract enterprise architecture rather than solution architecture.

TOGAF defines that: “Physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.”

Solution architecture is completed in phase G.

Preliminary Phase says “The solution development methodology is used … to plan, create, and deliver the architectural components specified in the portfolio and project charters.”

Phase B says “Architecture Definition will not be intended to give detailed or comprehensive requirements for a solution.”

Phase D says “Technology Architecture defines the physical realization of an architectural solution”

Phase D does not define Solution Building Blocks, since “Physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture.”

Phase E says “Create a Consolidated Gaps, Solutions, and Dependencies matrix, this enables identification of Solution Building Blocks which could potentially address one or more gaps and their associated architecture building blocks…. Create an overall solutions strategy.”

Phase G says “Perform gap analysis on enterprise architecture and solutions framework.” “The specific Solution Building Blocks required to fill these gaps will be the identified by the solutions architects.”

However, this picture is muddied in other parts of TOGAF; some of the artefacts in part 4 look to be solution level.

Ref 1: other papers at http://avancier.co.uk

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org