Recommended resources
The freely available resources this lesson will direct you to.
Welcome back. In the previous lesson, you saw why Requirements Management continues across the ADM: a requirement discovered later may change work done earlier. That raises a practical question. If architecture work has already moved on, what does it mean to “go back”?
This lesson distinguishes three scales of iteration: repeating an ADM cycle, moving between phases within a cycle, and refining work within one phase. You will use the customer-case handoff example from the previous lesson to see what changes at each scale. This distinction matters for understanding the ADM as a method you can adapt, rather than a fixed sequence you must follow exactly once.
The ADM diagram is a guide, not a one-way route
The familiar ADM diagram arranges the phases in a cycle, with Requirements Management at the center. The additional loops in this version make an important point: architecture work can revisit activities for different purposes.
Do not try to read each loop as an instruction to visit every phase it passes. Nor do the diagram’s labels—such as Architecture Development and Transition Planning—replace the three scales of iteration in this lesson. A loop may group several phases for a particular purpose. The first distinction to establish is simpler: what boundary does the iteration cross?
QualiWare’s Applying Iteration to the ADM explains why the phase-by-phase presentation can be misleading. It republishes older TOGAF guidance, so use it to understand the method, not as a source of exact 10th Edition exam wording.
Applying Iteration to the ADM | QualiWare Center of Excellence
Read the opening of QualiWare’s guide to understand why a sequential diagram does not imply a strictly sequential method.
In Section 19.1, “Overview,” read the opening explanation, from its discussion of the ADM graphic through its introduction of iteration and levels. Focus on the difference between a diagram that communicates the basic lifecycle and the way architecture work is actually carried out.
The ADM still has a meaningful structure. Phase A establishes a vision; architecture definition, planning, governance, and change management have different jobs. Iteration does not make those jobs interchangeable. It lets you return to the work needed to make an architecture coherent and useful.
Scale 1: iteration between ADM cycles
Imagine an initial customer-service architecture initiative with a broad scope: how case handoffs should work across several teams. Its ADM cycle produces architecture and planning at that chosen level of detail. During planning, the organization identifies a further, more focused architecture engagement to specify how one group of receiving teams will access case history.
That focused engagement can undertake another ADM cycle, guided by the broader architecture. The first cycle has not simply “gone back to Phase B.” It has led to a distinct cycle of architecture work with its own scope and level of detail. Across multiple cycles, an organization can develop a fuller Architecture Landscape: the collection of architectures covering different parts or levels of the enterprise.
Read the short subsection on this scale of iteration.
Applying Iteration to the ADM | QualiWare Center of Excellence
Return to QualiWare’s guide for its explanation of how one ADM cycle can lead to more detailed architecture work in another.
In Section 19.5, “Iteration Considerations,” find Subsection 19.5.1, “Iteration between ADM Cycles.” Read the subsection text, stopping before Figure 19-3. Notice the roles of Phase F in initiating more detailed projects and of the higher-level architecture in guiding them. The figure is optional; the paragraph contains the distinction needed here.
The useful test is not “Have we drawn the ADM circle again?” It is: Are we undertaking another cycle of architecture development for an agreed scope, informed by work from a previous cycle? A new cycle need not reproduce every earlier activity at identical depth. Its work is shaped by its purpose and scope.
Scale 2: iteration between phases in one cycle
Now stay inside one customer-case architecture engagement. Suppose Phase B describes a handoff in which a receiving team sees the relevant case history. During Phase C, examination of the information and applications reveals that some notes must be restricted. The Phase B process description may therefore need revisiting: what information does the receiving team actually need to continue the case?
This is iteration between phases. Phase C has exposed a problem in work developed in Phase B, so the architects revisit Phase B and then reconcile the resulting business decision with the information-systems work. The engagement has not thereby become a new ADM cycle. It is still developing an integrated architecture for the same agreed initiative.
The earlier work is not discarded merely because a later phase raised a question. The team revisits the affected assumptions and outputs. Requirements Management, as covered previously, keeps the changed access requirement and its decisions visible; the phase work resolves their architectural implications.
QualiWare gives an example in which architecture development crosses several phases more than once. You need not memorize its illustrated “baseline first” approach as a required route; look for why another pass can improve the result.
Applying Iteration to the ADM | QualiWare Center of Excellence
Read QualiWare’s explanation of iteration across phases, then examine the first two “Architecture Development (Baseline First)” rows as an example, not a mandatory sequence.
In Section 19.5, “Iteration Considerations,” find Subsection 19.5.2, “Iteration within an ADM Cycle.” Begin with its opening paragraph. Then, below the captions for Figures 19-4 and 19-5, find the table headed “Iteration Cycle,” “Iteration,” “Purpose,” and “Description.” Read the first two baseline-first rows. Focus on how work across Business, Information Systems, and Technology Architecture can be revisited for a different purpose while remaining within one architecture-development cycle.
A return between phases can be substantial—for example, revisiting a business process after discovering an information constraint—or brief, such as checking whether a proposed technology choice still supports an agreed application need. The trigger is a need to reconcile work belonging to different phases, not a rule that every phase must be repeated.
Scale 3: iteration within a single phase
Iteration can be smaller still. Suppose the architects are working in Phase B and draft the customer-case handoff process. Service staff review it and explain that the receiving team must confirm ownership before the sending team closes its part of the case. The architects revise the process description and review it again—all within Phase B.
Here, no discovery in Phase C has prompted a return to Phase B, and no new ADM cycle has begun. The same phase’s activities are being repeated to make its architecture content accurate enough for the decisions it must support.
Visual Paradigm’s Comprehensive Guide to Iterative Development with TOGAF ADM describes this single-phase scale explicitly.
Comprehensive Guide to Iterative Development with TOGAF ADM - Visual Paradigm
Read Visual Paradigm’s account of repeating activities within one phase, to contrast it with the cross-phase example above.
In Section 1, “Levels of Iteration within the ADM,” go to Subsection 1.3, “Cycling Around a Single Phase.” Read the description and benefits. Stop before Section 2, “Iterative Approaches in TOGAF ADM.” Focus on what is being refined, rather than interpreting “cycling” as starting the entire ADM again.
The boundary between the last two scales is easy to miss. Revising a Phase B description while doing Phase B work is within-phase iteration. Returning to Phase B because Phase C exposed an incompatibility is between-phase iteration. Both may change the same description; what distinguishes them is the scope of work being revisited.
Here is the comparison in one place:
| Scale | What is repeated or revisited? | Customer-case example |
|---|---|---|
| Between ADM cycles | Architecture development for another agreed scope or level, informed by an earlier cycle | A broad handoff architecture informs a later, more focused architecture engagement |
| Between phases, within a cycle | Work in different ADM phases to keep one engagement’s architecture consistent | A Phase C access constraint prompts reconsideration of the Phase B handoff process |
| Within a phase | Activities and content belonging to one phase | Phase B stakeholders review and refine a draft handoff process |
These scales can coexist. An architecture team might revise its Phase B model several times, return to it after Phase C work, and eventually see the completed engagement inform a separate ADM cycle. Calling all of that simply “the ADM is iterative” is true, but not precise enough to explain what the team is doing.
Key takeaways
Iteration between ADM cycles develops architecture across distinct cycles, often at different scopes or levels. Iteration between phases revisits work across phase boundaries to make one cycle’s architecture consistent. Iteration within a phase repeats that phase’s activities to refine its content. Requirements Management remains continuous through these movements, keeping changed requirements and decisions connected to the work they affect.
Next, you will look more closely at how the ADM operates at different levels of the enterprise. That will make the relationship between a broad architecture cycle and a more focused one easier to recognize.