4.1 The ADM Cycle, Its Phases & Information Flow
Key Takeaways
- The TOGAF ADM describes a method for developing and managing the lifecycle of an Enterprise Architecture and forms the core of the TOGAF Standard.
- The ADM consists of the Preliminary Phase, Phases A through H, and a continuous Requirements Management phase at the center of the cycle.
- For each ADM iteration, a fresh decision is taken on breadth of coverage, level of detail, time period, and architectural assets to leverage.
- The ADM does not mandate a specific phase sequence or a waterfall method, and outputs from an early phase may be modified in a later phase.
- Phase F produces the Implementation Governance Model that Phase G uses, and Phase H can issue a new Request for Architecture Work to start another cycle.
4.1 The ADM Cycle, Its Phases & Information Flow
"Introduction to the ADM" is the largest area of the OGEA-101 exam plan — 14 of 40 questions. This section covers two of its learning outcomes: briefly describe the ADM and its phases, and explain the information flow between the ADM phases.
What the ADM Is
The TOGAF Architecture Development Method (ADM) "describes a method for developing and managing the lifecycle of an Enterprise Architecture, and forms the core of the TOGAF Standard." It integrates elements of the TOGAF Standard, as well as other available architectural assets, to meet the business needs of an organization. The glossary calls it "a multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation."
The ADM provides a tested and repeatable process for developing architectures. It includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures, all within an iterative cycle of continuous architecture definition and realization.
The Phases of the ADM
| Phase | What the TOGAF Standard says the phase does |
|---|---|
| Preliminary | Describes the preparation and initiation activities required to create an Architecture Capability, including customization of the TOGAF framework and definition of Architecture Principles |
| A. Architecture Vision | Describes the initial phase of an architecture development cycle: defining the scope of the initiative, identifying stakeholders, creating the Architecture Vision, and obtaining approval to proceed |
| B. Business Architecture | Describes the development of a Business Architecture to support the agreed Architecture Vision |
| C. Information Systems Architectures | Describes the development of Information Systems Architectures (Data and Application) to support the agreed Architecture Vision |
| D. Technology Architecture | Describes the development of the Technology Architecture to support the agreed Architecture Vision |
| E. Opportunities & Solutions | Conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases |
| F. Migration Planning | Addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan |
| G. Implementation Governance | Provides an architectural oversight of the implementation |
| H. Architecture Change Management | Establishes procedures for managing change to the new architecture |
| Requirements Management | Operates the process of managing architecture requirements throughout the ADM |
Each phase is divided into steps, with defined inputs and outputs. The Requirements Management phase sits at the center of the cycle as a continuous phase that ensures changes to requirements are handled through appropriate governance processes and reflected in all other phases.
Key Points About the ADM
The ADM chapter lists the points you must know:
- The ADM is iterative — over the whole process, between phases, and within phases (see Section 4.2).
- For each iteration, a fresh decision must be taken on the breadth of coverage of the enterprise, the level of detail, the time period (including any intermediate periods), and the architectural assets to leverage (from previous ADM cycles and from the wider industry).
- These decisions should be based on a practical assessment of resource and competence availability and the value that can realistically be expected.
- As a generic method, the ADM may be — but does not necessarily have to be — tailored to specific needs, including use with another framework's deliverables.
- There needs to be frequent validation of results against the original expectations, for the whole cycle and for each phase.
- Output is generated throughout the process, and an output from an early phase may be modified in a later phase. The status of outputs at each stage is defined.
- The ADM does not mandate that phases are performed in a specific sequence, and does not mandate a waterfall method. It is helpful to view the ADM graphic as a reference model of what has to be done, rather than a rigid process model.
The ADM, the Enterprise Continuum, and the Repository
The Enterprise Continuum provides context for leveraging relevant assets while executing the ADM. At relevant places the ADM reminds architects to consider which assets from the Architecture Repository to use, and each execution of the ADM adds content to the repository. The first execution is often the hardest because re-usable assets are scarce.
Information Flow Between the Phases
The ADM phases hand information to each other through inputs and outputs, and many deliverables are created in one phase and refined in later ones. The table traces the main flow.
| From | Key outputs | Consumed by |
|---|---|---|
| Preliminary | Organizational Model for EA; Tailored Architecture Framework, including Architecture Principles; initial Architecture Repository; business principles, goals, and drivers; Architecture Governance Framework; Request for Architecture Work | Phase A (and every later phase uses the framework, principles, and repository) |
| Phase A | Approved Statement of Architecture Work; Architecture Vision; refined business principles, goals, and drivers; Architecture Principles; Capability Assessment; Communications Plan; draft Architecture Definition Document | Phases B, C, D and all later phases |
| Phases B, C, D | Draft Architecture Definition Document and draft Architecture Requirements Specification content for each domain; candidate Architecture Roadmap components; updated Phase A deliverables | Phase E; Requirements Management |
| Phase E | Initial complete version of the Architecture Roadmap, including Transition Architectures and work packages; updated Capability Assessment; draft Implementation and Migration Plan with the implementation and migration strategy | Phase F |
| Phase F | Finalized Architecture Roadmap; detailed Implementation and Migration Plan; finalized ADD and ARS; Implementation Governance Model; Change Requests arising from lessons learned | Phase G |
| Phase G | Signed Architecture Contract; Compliance Assessments; Change Requests; architecture-compliant solutions deployed | Phase H |
| Phase H | Architecture updates; changes to the framework and principles; a new Request for Architecture Work when a new cycle is needed | Phase A of the next cycle, or earlier phases for smaller changes |
| Requirements Management | Requirements Impact Assessment; changed requirements reflected in the Architecture Requirements Specification | Any phase affected by the change |
Reading the Flow
- The Request for Architecture Work starts a cycle; the Statement of Architecture Work defines and approves its scope.
- The Architecture Vision bounds detailed work in Phases B–D.
- Phases B–D build up the ADD (the architecture) and the ARS (the requirements an implementation must meet) and identify roadmap components.
- Phase E turns consolidated gaps into an Architecture Roadmap; Phase F makes it an agreed, prioritized Implementation and Migration Plan and defines the Implementation Governance Model.
- Phase G governs delivery through Architecture Contracts and Compliance Assessments.
- Phase H decides how to handle change — sometimes producing a new Request for Architecture Work, which feeds a new cycle.
- Requirements Management runs throughout, assessing the impact of changed requirements on current and previous phases.
Common Exam Pitfalls
- Treating Requirements Management as a one-time step. It is a continuous phase interacting with all other phases.
- Assuming outputs are frozen at the end of a phase. TOGAF says outputs from early phases may be modified later.
- Believing the ADM is a mandatory sequence. The ADM does not mandate a specific phase sequence or a waterfall method.
- Mixing up Request and Statement of Architecture Work. The Request triggers the cycle; the Statement is the approved Phase A output that defines the work.
Which ADM phase "conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases"?
Which statement about outputs in the TOGAF ADM is correct?
Which phase produces the Implementation Governance Model that is used to govern implementation in Phase G?
According to the TOGAF Standard, what must be decided afresh for each iteration of the ADM?