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 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:

 

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:

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:

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

 

Governance processes must be based on-going compliance reviews to

 

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:

 

The change management process should include,

 

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:

 

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:

 

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:

 

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

 

TOGAF outlines a ten step process for requirements management..

 

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

And two levels of impact analysis:

 

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