Iteration inside and across ADM cycles

Some teams distrust iteration because they confuse it with lack of control. TOGAF treats it differently. The standard 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.

C220, Applying the ADM describes iteration at multiple levels and names four iteration cycles. 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 Capability iteration

The first named cycle in the standard covers the Preliminary Phase and Phase A. Architecture Capability iterations create and evolve the architecture capability itself: mobilising the architecture activity for a given purpose or engagement type by establishing or adjusting the architecture approach, principles, scope, vision, and governance.

This cycle matters because the capability is never finished. A new engagement type, a change in sponsorship, or a shift in how much architecture the enterprise will absorb all trigger another pass through the Preliminary Phase and Phase A to reset the approach before development work resumes.

Pattern 4: Architecture Development iteration

C220, Applying the ADM describes this cycle as creating architecture content by cycling through, or integrating, the Business, Information Systems, and Technology Architecture phases (Phases B, C, and D). The enterprise may iterate through these development phases multiple times, each cycle increasing the breadth or depth of the architecture and keeping the three domains consistent with one another.

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 5: 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 6: 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 7: 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.

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 6) 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.

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.

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.

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.