The Architecture Development Method is often drawn as a circular sequence of phases, which can tempt teams to interpret TOGAF as a large waterfall. The method is more flexible than that picture suggests. The ADM is iterative across the whole cycle, between phases, and within phases. Scope, level of detail, time horizon, and use of existing architecture assets can be adjusted as the work develops.<\/p>\n
That matters because enterprise architecture is built under uncertainty. Stakeholders learn as options become concrete, constraints emerge, technology changes, and implementation provides evidence. Current TOGAF 10 guidance retains the ADM as a core part of the Fundamental Content while adding more modular Series Guides for practical use. Learners coming from the TOGAF 9 Certified<\/a> lineage should recognize continuity in the ADM while also understanding that the current certification portfolio is based on the TOGAF Standard, 10th Edition.<\/p>\n Iteration is therefore not a sign that the architecture team failed to plan. It is how the method controls complexity: develop enough architecture to make the next good decision, validate it, and deepen or redirect the work as evidence improves.<\/p>\n An ADM cycle needs boundaries: which enterprise segment is in scope, which architecture domains are required, how much detail is needed, what time horizon matters, and which stakeholders must be satisfied. Trying to solve the whole enterprise at maximum detail in one pass creates a model that is slow to produce and obsolete before it is complete.<\/p>\n A first iteration may establish direction and major dependencies. Later iterations can deepen a capability, domain, product, geography, or transition state. The architecture team should be able to explain why the selected breadth and depth are sufficient for the decisions that must be made now.<\/p>\n Requirements do not appear once at the beginning and then remain frozen. The ADM treats requirements as something that is identified, stored, addressed, and updated throughout the cycle. Architecture work can reveal new constraints or invalidate old assumptions, and those findings should feed back into requirements rather than being hidden as design exceptions.<\/p>\n This makes traceability important. A requirement should connect to the stakeholder concern or business driver that produced it, the architecture decisions that address it, and any trade-off or exception that changes its treatment.<\/p>\n Business, data, application, and technology architecture influence one another. A data-residency constraint can change application placement. A technology platform limit can affect business operating models. An application integration pattern can change data ownership. Treating each domain as a sealed phase produces late surprises.<\/p>\n Iteration allows architects to move between domains as dependencies become visible. The goal is not endless cycling; it is enough cross-domain validation to avoid optimizing one architecture at the expense of another. The security and enterprise architecture<\/a> discussion illustrates the same issue: trust boundaries cannot be designed independently from systems and operating processes.<\/p>\n Phase A establishes the vision, stakeholders, scope, and value proposition for the architecture work. Later analysis may reveal that the original transformation is too expensive, too risky, or based on weak assumptions. The team should be willing to revisit the vision instead of forcing later phases to justify an outdated premise.<\/p>\n This is a governance strength. Revisiting the vision can prevent sunk-cost thinking and make strategic trade-offs visible before implementation consumes more resources.<\/p>\n Many enterprises cannot move directly from baseline to target. Intermediate states can reduce risk, align dependencies, and sequence investment. Each transition architecture creates an opportunity to validate assumptions before committing to the next state.<\/p>\n The architecture should define what is intentionally temporary and what must remain stable. Otherwise transitional components can become permanent by inertia. Iterative planning needs exit criteria, not merely more phases.<\/p>\n Implementation governance should test whether delivery remains conformant with the architecture and whether the architecture itself remains viable. A deviation may indicate poor implementation, but it can also reveal that the architecture missed an operational constraint. The answer should come from evidence, not from defending the original document.<\/p>\n This connects to the completed architecture principles<\/a> discussion: governance is credible when it can distinguish justified exceptions from silent drift and when repeated exceptions lead to review of the governing rule.<\/p>\n Architecture teams can continue modelling indefinitely because every view exposes another question. Iteration needs completion criteria tied to decisions. A phase or cycle can stop when stakeholders have enough reliable information to approve direction, compare options, authorize investment, or govern implementation.<\/p>\nIteration begins with deliberate scope<\/h3>\n
Requirements management creates a continuous feedback path<\/h3>\n
Iterations between domains prevent false sequencing<\/h3>\n
Architecture vision should be revisited when evidence changes the proposition<\/h3>\n
Transition architectures are natural iteration points<\/h3>\n
Implementation feedback belongs back in the architecture<\/h3>\n
Use checkpoints to stop unnecessary detail<\/h3>\n