In TOGAF's Architecture Development Method (ADM), the phases (Preliminary, then A through H) are drawn as a wheel around a central 'Requirements Management' phase rather than a straight top-to-bottom list. What does that layout signal about how the ADM is meant to be used, and why is Requirements Management placed at the center instead of being just the first step?

## The method and what its picture encodes The Architecture Development Method (ADM) is TOGAF's core process: a sequence of phases that together produce and maintain an enterprise architecture. - **Preliminary** - **A** — Architecture Vision - **B** — Business Architecture - **C** — Information Systems Architecture, covering Data and Application - **D** — Technology Architecture - **E** — Opportunities & Solutions - **F** — Migration Planning - **G** — Implementation Governance - **H** — Architecture Change Management TOGAF deliberately draws these phases as a ring rather than a waterfall list, and puts a phase called **Requirements Management** in the hub at the center of that ring, connected by spokes to every other phase. That picture is not decorative; it encodes two structural claims about how architecture work actually happens. ## The first claim — the ADM is a cycle The first claim is that the ADM is a cycle, not a project plan you execute once. **Phase H, Architecture Change Management**, exists specifically to watch the business and technology environment for changes — a new regulation, a merger, a platform end-of-life — and to decide whether those changes are significant enough to trigger a new pass through the ADM, starting again at the Preliminary Phase or Phase A. An organization that treats the ADM as 'do phases A through H once, ship a binder, done' has misunderstood it: the intent is a standing capability that re-enters the loop repeatedly over the organization's life, with each iteration producing a new **Target Architecture** that becomes the next iteration's **Baseline Architecture**. TOGAF also explicitly allows looping within a single pass — if Phase D's technology assessment reveals a platform can't support a data model chosen in Phase C, you go back and revise Phase C (and possibly B) before moving forward again. The ring communicates that backward and repeated traversal is expected behavior, not a process failure. ## The second claim — where requirements live The second claim is about where requirements live. In a naive reading of 'Preliminary, then A, then B...' you might expect requirements gathering to be a step that happens early and then be handed off, fixed, to the rest of the phases. TOGAF rejects that model on purpose. **Requirements Management** is drawn as a continuous, always-active phase with a direct connection to every other phase, because in practice each phase both consumes requirements that already exist and generates new ones as a side effect of its own analysis: - Phase B's business-process analysis might surface a requirement nobody wrote down in Phase A. - Phase D's technology-constraint analysis might invalidate an assumption baked into Phase B. If requirements were only handled once at the start, these mid-stream discoveries would have nowhere to go — they'd either get silently dropped, or force an ad hoc restart of the whole method. By making Requirements Management a standing phase with its own repository and process, the ADM gives every other phase a defined channel: raise a requirement into Requirements Management, and it routes the requirement to whichever phase owns resolving it, keeping a durable record of the requirement's status and disposition. ## The trade-off The trade-off this buys is **traceability at the cost of process overhead**. Every architecture decision in a mature TOGAF engagement can, in principle, be traced back to a requirement and forward to the work package that implements it — valuable in regulated industries or large programs where 'why did we build it this way' needs a paper trail years later. The cost is that Requirements Management has to be genuinely staffed and visited, not just diagrammed; teams that draw the wheel in a slide deck but never actually route mid-cycle findings back through a live requirements repository end up with the worst of both worlds — the overhead of formal phases without the traceability payoff. ## What goes wrong in practice A concrete failure mode: 1. A team runs Phase A, produces an Architecture Vision and a requirements list, and then treats that list as frozen going into Phases B through D. 2. Midway through Phase C, the data architects realize a regulatory data-residency requirement was never captured. 3. Because nobody is actively using Requirements Management as a live channel, the requirement gets addressed informally in a hallway conversation, never recorded, and resurfaces as a compliance gap during Phase G's implementation governance review — by which point the cost of the fix is far higher than it would have been if Requirements Management had caught it in Phase C. ## Where it shows up A worked example: a telecom running a multi-year OSS/BSS modernization typically executes several ADM loops — an initial full pass to set target Business, Data, Application, and Technology architectures, then smaller re-entries triggered by Phase H whenever a new regulatory reporting requirement or an acquired subsidiary's systems need to be absorbed, with Requirements Management carrying forward the accumulated requirement set across every loop rather than restarting from zero each time.