Iteration inside and across ADM cycles
This is the fourth of 8 Migration and Delivery modules. It explains the complete iteration technique from C220 Part 3, including every iteration pattern the standard defines, the governance controls that keep iteration disciplined rather than chaotic, and the practical signals that tell an architecture team when to loop, narrow, deepen, or start a new cycle. No knowledge beyond Module 46 is assumed.
By the end of this module you will be able to:
- Explain why the ADM should not be read as a rigid waterfall sequence and cite the C220 Part 3 guidance that makes this explicit
- Describe all iteration patterns from C220 Part 3: within-phase, cross-phase, Architecture Development iteration, Transition Planning iteration, and Architecture Governance iteration
- Explain the difference between iteration within a single ADM cycle and iteration across multiple ADM cycles
- Identify the signals that tell the architecture team when to loop, narrow, deepen, or begin a new cycle
- Describe the governance controls that keep iteration disciplined rather than chaotic
- Apply iterative TOGAF thinking to the London case and its changing evidence base across four domain threads
Real-world case · 2022
Phase D revealed the business architecture was wrong. The project plan said no going back.
A consulting team was engaged to run a TOGAF-based architecture programme for a mid-sized insurer. The team produced a detailed project plan with one pass through each ADM phase, each phase closing before the next opened.
When Phase D revealed that the business architecture assumptions from Phase B were based on an operating model the insurer had since abandoned, the programme manager asked whether the team could go back. The project plan said no. The architecture said yes.
The team chose the project plan, carried the flawed assumption forward, and delivered a technology architecture that solved the wrong business problem. Iteration is not a weakness. It is the mechanism that prevents architecture work from becoming a fiction that nobody is allowed to correct.
If a later phase reveals that an earlier assumption is wrong, should the architecture team carry the flaw forward because the project plan does not allow revisiting it?
That story illustrates what happens when iteration is treated as rework rather than as a control mechanism. This module explains every iteration pattern the standard defines and the governance discipline that keeps iteration productive.
If you are already confident with ADM iteration patterns, use the knowledge checks to confirm your understanding and move to Module 48: Architecture landscape and partitioning.
47.1 Why iteration is not a weakness
Some teams distrust iteration because they confuse it with lack of control. TOGAF treats it differently. C220 Part 3 is explicit: the ADM is designed to be iterative at every level. The circular shape of the ADM diagram is not decorative. It signals that the enterprise should expect to loop, revisit, and deepen rather than march through once and declare victory.
The goal is not to loop for its own sake. The goal is to revisit the right questions at the right moment so the architecture remains truthful and governable. Iteration is the mechanism through which the architecture absorbs new evidence, corrects earlier assumptions, and adapts to changes in scope, constraints, and enterprise reality.
The alternative to iteration is false certainty. An architecture that claims to be complete after one pass through each phase is either working on a problem simple enough not to need a framework, or it is carrying flawed assumptions that will surface during delivery, when the cost of correction is highest.
“The ADM is iterative, over the whole process, between phases, and within phases.”
The TOGAF Standard, 10th Edition - C220 Part 3, Applying the ADM
Three levels of iteration in one sentence. The ADM iterates within individual phases (refining outputs as evidence improves), between phases (revisiting earlier work when later work exposes problems), and across the whole process (running multiple ADM cycles as the enterprise evolves). All three levels are built into the method by design.
47.2 The complete iteration patterns from C220 Part 3
C220 Part 3 describes iteration at multiple levels. Understanding each pattern matters because they serve different purposes and require different governance responses.
Pattern 1: Within-phase iteration
The team refines a phase's outputs as better information becomes available or stakeholder concerns become sharper. This is the simplest form of iteration. For example, Phase B may begin with a coarse capability map. As interviews and workshops reveal more detail, the team refines the map, sharpens capability boundaries, and adjusts gap ratings. The phase is not repeated. Its outputs mature through progressive refinement.
Within-phase iteration is governed by the phase's own review criteria. The team continues refining until the phase outputs are sufficient for the next phase to proceed. The risk of within-phase iteration is perfectionism: the team refines endlessly because the outputs are never quite complete enough. Time-boxing and explicit sufficiency criteria prevent this.
Pattern 2: Cross-phase iteration (backward)
A later phase exposes a weakness that requires the architecture to revisit an earlier phase rather than quietly carrying the flaw forward. This is the pattern the opening story illustrated. Phase D work may reveal that the business architecture in Phase B was based on incorrect assumptions. Phase C may reveal that information authority rules assumed in Phase B do not hold.
Cross-phase iteration is more expensive than within-phase iteration because it requires revisiting outputs that the enterprise may consider closed. That is why it requires an explicit governance decision. The Architecture Board or its equivalent should approve the backward loop and define what specifically needs to be corrected. Undisciplined backward looping wastes time. Refusing to loop when evidence demands it wastes more.
Pattern 3: Architecture Development iteration
C220 Part 3 describes a specific iteration pattern that covers Phases A through D as a group. The enterprise may iterate through the architecture development phases (Preliminary, Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture) multiple times, each cycle increasing the breadth or depth of the architecture.
This pattern is common when the enterprise starts with a broad, shallow architecture to establish direction and then deepens specific areas in subsequent cycles. The first cycle might produce a strategic architecture across all domains. The second cycle might deepen the information architecture for a specific capability. The third might deepen the technology architecture for a specific platform.
Pattern 4: Transition Planning iteration
Phases E and F may iterate as the enterprise learns more about implementation feasibility, readiness, and cost. The initial groupings from Phase E may need to be revised after Phase F reveals that the sequencing logic does not hold. The migration plan may need to be adjusted after readiness assessment exposes unexpected gaps.
Transition Planning iteration is driven by evidence gates. Each gate tests whether the current plan is still valid. If the evidence says no, the enterprise loops back to regroup or resequence rather than proceeding on a plan that has been invalidated.
Pattern 5: Architecture Governance iteration
Phase G (Implementation Governance) and Phase H (Architecture Change Management) create feedback that may trigger a new Architecture Development iteration or a Transition Planning iteration. Compliance reviews may reveal that delivery has diverged from the architecture. Change requests from the business may require new architecture work. Technology changes in the market may invalidate assumptions in the current target architecture.
Architecture Governance iteration is what connects the ADM to the enterprise's ongoing life. Without it, the architecture becomes a snapshot that ages, rather than a living capability that adapts.
Pattern 6: Multi-level iteration
Enterprise-wide and initiative-level work proceed at different speeds and still need to inform one another. The enterprise-wide architecture may set principles and constraints that initiative-level architectures must respect. Initiative-level work may generate findings that update the enterprise-wide view.
Multi-level iteration requires explicit interfaces between the levels. The Architecture Repository is the primary mechanism for this. Enterprise-wide outputs are published to the repository. Initiative-level teams consume them as inputs. Initiative-level findings are fed back to the enterprise-wide view through governed channels.
Common misconception
“Iteration is wasteful because it means the architecture team did not get it right the first time.”
Iteration is how the architecture stays truthful as new evidence, stakeholder concerns, and delivery reality emerge. The cost of iteration is real but manageable. The cost of carrying wrong assumptions forward is usually much higher. The standard builds iteration into every level of the ADM precisely because getting it right first time on complex enterprise problems is unreliable.
47.3 Iteration within a cycle versus across cycles
The distinction between iteration within a single ADM cycle and iteration across multiple cycles is important for governance and planning.
Within a single cycle, iteration refines and corrects the outputs of the current architecture engagement. The enterprise is working on one defined scope with one set of stakeholders and one set of objectives. Within-phase and cross-phase iteration both happen inside a single cycle. The governance authority is the Architecture Board for that engagement.
Across multiple cycles, iteration reflects the enterprise's ongoing evolution. Each cycle addresses a different scope, a deeper level of detail, or a changed business context. The first cycle might produce a strategic architecture. The second might produce solution architectures for specific initiatives. The third might respond to a market change that invalidates part of the target.
The Architecture Governance iteration (Pattern 5) is what connects cycles. Phase H triggers a new cycle when the architecture needs to change. The Requirements Management process maintains continuity between cycles by tracking what changes, what remains valid, and what needs to be reconsidered.
47.4 Signals that the architecture should loop
Recognising when to iterate is as important as knowing how. The following signals indicate that the architecture should revisit earlier work rather than carrying a known weakness forward.
- Assumption invalidation. A dependency or stakeholder concern emerges that changes the scope materially. The operating model has changed. A regulation has been updated. A market assumption no longer holds.
- Authority or boundary weakness. An assumed authority or boundary turns out to be weaker than expected. The data ownership assumed in Phase B is contested. The organisational boundary assumed in Phase C has moved.
- Delivery reality gap. Delivery reality exposes a gap in the transition logic or readiness assumptions. The technology that was assumed to be available is not. The organisational capacity to absorb change is lower than estimated.
- Evidence gate failure. An evidence gate shows that the current plan is no longer justified cleanly enough to move on. Exit conditions for a transition state have not been met. Readiness scores have dropped below the threshold.
- Stakeholder concern escalation. A stakeholder raises a concern that was not visible in the earlier phases but materially affects the architecture. This is especially common when stakeholder engagement was incomplete in earlier phases.
- Cross-domain conflict. A decision in one domain creates an unresolvable conflict with a decision in another domain. The information architecture requires a data standard that the technology architecture cannot support with the chosen platform.
- Scope change request. A formal change request from Requirements Management adds, removes, or modifies a significant requirement. The architecture must absorb the change rather than ignoring it.
47.5 Governance of iteration
Ungoverned iteration is chaos. Governed iteration is learning. The difference depends on four controls.
Explicit decision to loop. The decision to revisit an earlier phase or start a new cycle should be taken by the Architecture Board, not by individual team members. This prevents uncontrolled scope changes while still allowing the architecture to respond to evidence.
Defined scope of the loop. When the architecture loops back, the scope of what needs to change should be defined. "Revisit Phase B" is too broad. "Revisit the capability assessment for connection handling because the operating model has changed" is specific enough to control.
Impact assessment. Before looping, the team should assess what downstream outputs will be affected. If correcting a Phase B assumption invalidates a Phase D decision, the downstream impact must be understood before the loop begins.
Time and resource bounds. Iteration should be time-boxed to prevent perfectionism from consuming the engagement. The Architecture Board should define how long the loop is expected to take and what evidence will confirm that the correction is sufficient.
47.6 London Grid Distribution: iteration in practice
London is exactly the kind of case that needs iteration at multiple levels. Business pressure, information quality, transition-state logic, cyber assurance, and delivery readiness do not all mature together. The architecture therefore has to loop without losing control.
Within-phase iteration in London
The information architecture for publication quality will be refined multiple times as the team discovers which data sources are authoritative and which are contested. The first pass may identify ten publication types. The second may reveal that three of those types have no clear data owner. The refinement continues until the authority map is sufficient for publication-channel migration to proceed.
Cross-phase iteration in London
If Phase D (Technology Architecture) reveals that the chosen case-management platform cannot enforce the data-authority rules defined in Phase C, the architecture must loop back. Carrying the incompatibility forward would mean building a system that cannot enforce its own governance rules.
Transition Planning iteration in London
The first evidence gate may reveal that governance readiness is lower than the roadmap assumed. That finding should trigger a Transition Planning iteration that adjusts the pace or order of work packages rather than proceeding on a plan that the enterprise cannot absorb.
Multi-level iteration in London
The enterprise-wide architecture sets principles for data authority, publication discipline, and resilience assurance. Initiative-level work on the connections case spine may discover that a principle needs clarification or that an exception is required. That finding should flow back to the enterprise-wide architecture through the repository, not remain hidden at the initiative level.
A Phase D analysis reveals that two business capabilities assumed in Phase B no longer exist in the current operating model. What should the architecture team do?
C220 Part 3 describes iteration at three levels. Which three?
An architecture team decides to loop back from Phase E to Phase B without informing the Architecture Board. What governance principle has been violated?
What is the difference between Architecture Development iteration and Transition Planning iteration?
Key takeaways
- C220 Part 3 defines iteration at three levels: within phases, between phases, and over the whole ADM process.
- Six specific iteration patterns cover Architecture Development, Transition Planning, Architecture Governance, cross-phase, within-phase, and multi-level iteration.
- Iteration within a cycle refines the current engagement. Iteration across cycles reflects the enterprise's ongoing evolution.
- Seven signals indicate when the architecture should loop: assumption invalidation, authority weakness, delivery reality gap, evidence gate failure, stakeholder escalation, cross-domain conflict, and scope change request.
- Four governance controls keep iteration disciplined: explicit decision, defined scope, impact assessment, and time bounds.
- London needs iteration at every level because its four domain threads mature at different speeds and the evidence base changes continuously.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
Part 3, Applying the ADM: iteration, adaptation, and cycle management
The core standard covering all iteration patterns, levels of iteration, and adaptation guidance for the ADM. The primary source for this module.
G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM
Full guide
Practical guidance on iterative architecture work within the ADM, including cycle management examples.
G212, Architecture-Led Incremental Planning
Full guide
Incremental planning techniques that complement the iteration patterns from C220 Part 3.
Full guide
Agile iteration patterns that relate to ADM iteration, covered in more depth in Module 49.
You now understand iteration as a governed control mechanism with six patterns, seven trigger signals, and four governance controls. The next question is how large architecture efforts are partitioned into manageable portions without hiding the joins that matter. That is Module 48.
Module 47 of 64 · Migration and Delivery