The ADM is the single most important thing in TOGAF — it's the method that turns 'we should do architecture' into a repeatable sequence of steps with defined inputs and outputs. Almost every other part of the Standard exists to support the ADM.

If you can draw the ADM cycle from memory and say what each phase produces, you've covered a large slice of the Foundation exam and you have the mental model a practitioner uses every day.

The Architecture Development Method (ADM) is a tested, repeatable process for developing and managing the lifecycle of an enterprise architecture. It defines, for each phase, the objectives, inputs, steps and outputs.

Crucially the ADM is iterative — over the whole cycle, between phases, and within a single phase. You are expected to tailor it (via iteration and architecture partitioning) rather than march through it once, linearly.

Preliminary — prepare & initiate: tailor TOGAF, stand up the architecture capability, agree principles and governance. A · Architecture Vision — scope, stakeholders, the aspirational Vision; delivers the Statement of Architecture Work. B · Business → C · Information Systems (Data + Application) → D · Technology — develop the target architectures and run gap analysis against the baseline. E · Opportunities & Solutions — first-cut implementation planning; group gaps into work packages. F · Migration Planning — the detailed, costed Implementation & Migration Plan. G · Implementation Governance — architectural oversight while it's built. H · Architecture Change Management — manage change to the deployed architecture, deciding whether a change triggers a new ADM cycle.

Say the loan-approval programme reaches Phase C. Inputs: the Statement of Architecture Work (from A) and the target Business Architecture (from B). Steps: model the target Data and Application architectures, then gap-analyse against today's systems. Output: the Information Systems Architecture plus a gap list that flows into Phase E to become work packages. That input→step→output shape repeats in every phase.

Requirements Management sits at the centre of the cycle. It is a continuous process, not a phase you complete once: every phase feeds requirements in and draws them out. It governs how architecture requirements are identified, stored, and fed into and out of the relevant phases — but it does not dispose of requirements itself; the phases do that.

The phases realise the BDAT domains (B/C/D). Phase A builds on the core concepts (TGF‑C1). The Enterprise Continuum & Repository (TGF‑C3) is where ADM outputs are stored and reused, and deliverables/building blocks (TGF‑C4) are what each phase produces. Governance (a later topic) is exercised continuously and sharply in Phase G.