14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement

14.2 ADM Iteration Types: Capability, Architecture Development, and Transition Planning Iterations

A frequent misconception among novice architects and waterfall project managers is that the TOGAF Architecture Development Method (ADM) represents a rigid, sequential progression starting at the Preliminary Phase and proceeding strictly in single-file order through Phase H. In reality, the TOGAF Standard positions the ADM as an inherently iterative framework.

Iteration occurs at multiple scales: within an individual phase, across clusters of related phases, and across the enterprise as a whole. On the OGEA-103 practitioner examination, candidates must demonstrate how to apply, sequence, and manage the four recognized ADM iteration cycles, distinguish between cycling and cascading, and orchestrate multi-speed architectural cadences across enterprise tiers.

---

Three Senses of Iteration in TOGAF

The ADM graphic can be read as a waterfall, but TOGAF states that two key concepts manage complexity in practice: iteration and levels. It describes iteration in three senses:

1. Iteration to develop a comprehensive Architecture Landscape: each ADM cycle is bound by a Request for Architecture Work, and successive cycles populate or change the landscape. Separate projects may run their own ADM cycles concurrently, and one project may trigger another.
2. Iteration within an ADM cycle (Architecture Development iteration): projects may run several phases concurrently, cycle between phases in planned cycles, or return to earlier phases to update work products with new information.
3. Iteration to manage the Architecture Capability (Architecture Capability iteration): a new iteration of the Preliminary Phase may be needed to establish or adjust the capability, for example when Phase A finds it lacking, or when a Phase H Change Request identifies new capability requirements.

Iteration and Levels

Architectures at different levels (Strategic, Segment, Capability) can be developed in two ways. TOGAF describes developing them through iterations within a single ADM cycle, or through a hierarchy of ADM processes executed concurrently, where Phase F of a higher-level cycle initiates more detailed architecture projects. In practice architects blend the two to fit the Request for Architecture Work.

Baseline First or Target First

TOGAF describes two approaches within Architecture Development iterations:

• Baseline First: assess the baseline to identify problems and improvement opportunities. This suits a baseline that is complex, not clearly understood, or not agreed, which is common where organizational units have been highly autonomous.
• Target First: elaborate the target in detail, then map back to the baseline to identify change. This suits a target that is agreed at a high level, where the enterprise wants to move effectively to the target model.

TOGAF adds that if the baseline is broadly understood, more value usually comes from focusing on the target first and examining the baseline only as far as needed to identify changes.

---

The Four Distinct TOGAF ADM Iteration Cycles

The TOGAF Standard formally identifies four core iteration cycles across the ADM:

+-------------------------------------------------------------------------+
|               1. Architecture Capability Iteration                      |
|                    (Preliminary <---> Phase A)                          |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|             2. Architecture Development Iteration                       |
|                  (Phase B <---> Phase C <---> Phase D)                  |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|               3. Transition Planning Iteration                          |
|                     (Phase E <---> Phase F)                             |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|               4. Architecture Governance Iteration                      |
|                     (Phase G <---> Phase H)                             |
+-------------------------------------------------------------------------+

---

1. Architecture Capability Iterations (Preliminary & Phase A)

Focus: Establishing, evaluating, and evolving the enterprise architecture capability itself, alongside defining the strategic mandate for architecture work.

• Mechanics: Architects cycle between the Preliminary Phase and Phase A. In the Preliminary Phase, the team establishes the governance charter, configures tools, tailors the ADM, and evaluates organizational capability maturity. In Phase A, the team receives a Request for Architecture Work, defines the Architecture Vision, identifies key stakeholders, and scopes the initiative.
• Why It Cycles: When defining the Architecture Vision in Phase A, stakeholders may demand business transformations that exceed the current governance authority or technical maturity established in the Preliminary Phase. Cycling back to Preliminary allows the organization to update the Architecture Board charter, expand toolsets, or adjust tailoring parameters to accommodate the vision before signing the Statement of Architecture Work (SoAW).
• Key Triggers: Mergers, acquisitions, major digital transformations, corporate restructuring, or entering heavily regulated new markets.

---

2. Architecture Development Iterations (Phases B, C, and D)

Focus: Developing and harmonizing the comprehensive Target Architecture across Business, Data, Application, and Technology domains.

• Mechanics: The architecture team cycles iteratively among Phase B (Business Architecture), Phase C (Information Systems Architectures: Data and Application), and Phase D (Technology Architecture).
• The Fallacy of Linear Execution: Linear execution (B then C then D) assumes that business processes can be designed in total isolation from technology realities. In modern enterprises, technology is often a primary business driver. An innovative technology capability (e.g., real-time streaming infrastructure in Phase D) can unlock brand-new business models in Phase B. Conversely, data governance regulations identified in Phase C can impose strict physical hosting constraints in Phase D.
• Convergence: The team loops through B, C, and D until the baseline models, target models, gap analyses, and Architecture Requirements Specifications converge into a harmonious, fully validated Architecture Definition Document (ADD).

---

3. Transition Planning Iterations (Phases E and F)

Focus: Bridging the theoretical Target Architecture with physical implementation realities, capital funding, delivery constraints, and organizational roadmaps.

• Mechanics: The architecture team cycles between Phase E (Opportunities and Solutions) and Phase F (Migration Planning).
• Why It Cycles: In Phase E, architects consolidate gap analysis results from Phases B-D, formulate logical work packages, evaluate Solution Building Blocks (SBBs), and sketch initial candidate Transition Architectures. In Phase F, the team collaborates with the PMO, operations, and finance to assess business value, estimate costs, analyze implementation risks, and evaluate portfolio capacity.
• The Value-Cost Trade-Off: If Phase F financial analysis reveals that the initial migration plan exceeds capital budget caps or requires impossible operational downtime, the team cannot simply abandon the project. Instead, they cycle back to Phase E to restructure work packages, define additional intermediate Transition Architectures, or phase out legacy systems incrementally. This negotiation loops until a realistic, funded Implementation and Migration Plan is finalized.

---

4. Architecture Governance Iterations (Phases G and H)

Focus: Maintaining operational oversight during project implementation and managing continuous architectural change once systems enter production.

• Mechanics: Governance cycles between Phase G (Implementation Governance) and Phase H (Architecture Change Management).
• The Governance Feedback Loop: During Phase G, architects conduct Architecture Compliance Reviews and manage Architecture Contracts. As solutions deploy into production, Phase H monitors ongoing business value realization, tracking whether the implemented architecture delivers expected benefits and monitoring external technology disruptions.
• Closing the Loop: Minor variances, routine maintenance, and tactical deviations identified during Phase G implementation feed directly into Phase H change assessments. When Phase H detects that cumulative changes or strategic disruptions exceed existing architectural boundaries, it classifies the change and determines whether to issue an incremental update or initiate a brand-new ADM cycle (looping back to Phase A or Preliminary).

---

Classes of Architecture Engagement

TOGAF groups architecture engagements into three areas, with six engagement types, and indicates which iteration cycles each emphasizes:

The table is a good Part 2 tool. If a scenario describes a bounded initiative whose vision is already agreed, target-first development followed by transition planning is the natural emphasis. If it describes governing projects already underway, the Architecture Governance cycle dominates. TOGAF also notes that the Architecture Development cycle extends into Phases E and F as it converges, so implementability is considered while the architecture is finalized. Checkpoints can be frequent and informal when stakeholder involvement is high, or less frequent but more formal when it is low.

---

Comparison Table: The Four TOGAF ADM Iteration Cycles

---

Practitioner Exam Scenario: Multi-Speed Iteration at Omnichannel Retailer

Scenario: MetroMart, a national retail chain with 800 physical stores, initiates a major digital commerce expansion. The Chief Architect organizes the architecture work into multi-speed iteration cycles:

1. Capability Iteration: The team identifies that the existing Architecture Board charter only covers traditional physical store point-of-sale (POS) hardware. Cycling between Preliminary and Phase A, the board updates its governance charter to incorporate cloud platforms and mobile applications, approving a new Statement of Architecture Work.
2. Architecture Development Iteration: In Phase B, business architects design a "Buy Online, Pick Up in Store" (BOPIS) customer journey. Moving to Phase C, data architects uncover that the inventory database updates in 24-hour batches, which would cause customers to purchase out-of-stock items. Moving to Phase D, technology architects identify that an event-driven streaming platform can achieve sub-second inventory updates. The team cycles back through C and B to revise application integration flows and business service levels, producing a coherent Target Architecture.
3. Transition Planning Iteration: In Phase E, the team proposes a complete cutover to the new streaming platform in October. In Phase F, business leadership objects: executing cutover in October introduces catastrophic risk to November-December holiday shopping trading. Cycling back to Phase E, the team defines an intermediate Transition Architecture 1 (TA-1) that provides a temporary caching layer for holiday trading, deferring full database cutover to Transition Architecture 2 (TA-2) in February.
4. Governance Iteration: During Phase G rollout of TA-1, an unexpected network latency spike is identified in older physical stores. Phase H evaluates the operational impact, issuing an incremental change request to deploy edge caching nodes in affected locations without derailing the overall enterprise roadmap.

---

Common Exam Traps & Pitfalls

• Trap 1: Treating Transition Planning as a One-Way Phase F Activity: Distracter options often depict Phase E finishing its work and handing off deliverables to Phase F without further interaction. In reality, Transition Planning is an active, iterative negotiation between E and F; financial and scheduling realities in F routinely force re-architecting in E.
• Trap 2: Confusing Architecture Development Iterations with Software Sprints: Cycling through Phases B, C, and D is an architectural modeling and trade-off activity designed to produce target blueprints and building blocks. It is not equivalent to two-week software engineering coding sprints.
• Trap 3: Believing Any Phase H Change Requires a Full New ADM Cycle: Phase H classifies changes into Simplification, Incremental, and Re-Architecting. Only major Re-Architecting changes warrant cycling back to Phase A for a full ADM cycle; simplification and incremental changes are resolved within ongoing governance iterations.