TOGAF & the ADM¶

If ArchiMate is the language, TOGAF is the method — how an architecture practice actually runs. Its beating heart is the Architecture Development Method (ADM): a repeatable cycle that turns strategy into a governed change programme, one architecture at a time. This page walks the cycle, says what each phase produces, and maps those deliverables onto the ArchiMate layers you met in the Overview.

What TOGAF gives you¶

TOGAF is more than the ADM, but four parts do most of the work:

The ADM — the step-by-step cycle (Preliminary, then Phases A–H) with Requirements Management running throughout.
Deliverables, artefacts, and building blocks — the standard outputs each phase creates (an Architecture Vision, a Business Architecture, an Implementation & Migration Plan, …).
The Architecture Repository — where those outputs live and are reused: the Architecture Landscape, a Reference Library, a Standards Information Base, and a Governance Log.
Architecture Governance — the board, contracts, and compliance reviews that keep delivery aligned to the agreed architecture.

TOGAF is meant to be tailored

The ADM is a framework, not a fixed checklist. Real practices tailor it — collapsing phases for small changes, iterating B–D for large ones, and setting their own governance cadence. Treat what follows as the full shape; use the parts your change actually needs.

The ADM cycle¶

The ADM is a cycle for a reason: architecture is never "done". Each turn takes the enterprise from a baseline ("as-is") to a target ("to-be") for a defined scope, then feeds change management, which decides when the next turn begins.

flowchart TD
    P[Preliminary<br/>establish the capability] --> A
    A[A · Architecture Vision] --> B[B · Business Architecture]
    B --> C[C · Information Systems<br/>Data & Application]
    C --> D[D · Technology Architecture]
    D --> E[E · Opportunities & Solutions]
    E --> F[F · Migration Planning]
    F --> G[G · Implementation Governance]
    G --> H[H · Architecture Change Management]
    H -->|next iteration| A
    RM{{Requirements<br/>Management}}
    RM --- A
    RM --- B
    RM --- C
    RM --- D
    RM --- E
    RM --- F
    RM --- G
    RM --- H

The ADM: Preliminary sets up the practice; Phases A–H run the cycle from vision to change management; Requirements Management sits in the centre, feeding and draining every phase. Phase H loops back to A for the next iteration.

What each phase produces¶

The value of the ADM is that every phase has a defined output that the next phase consumes. Learn the deliverables and the method stops feeling abstract.

Phase	Purpose	Key deliverables
Preliminary	Stand up the architecture capability and tailor TOGAF to your org	Architecture Principles, tailored framework & tools, Architecture Governance model, Request for Architecture Work
A · Architecture Vision	Agree scope, stakeholders, and an aspirational target	Architecture Vision, Statement of Architecture Work, stakeholder map, refined principles, business value & KPIs
B · Business Architecture	Baseline & target for org, functions, processes, services	Business Architecture (baseline + target), gap analysis, updated Architecture Definition Document
C · Information Systems	Data + Application architectures to support the business	Data Architecture, Application Architecture, gap analysis
D · Technology Architecture	The infrastructure that realises the apps	Technology Architecture (baseline + target), gap analysis
E · Opportunities & Solutions	Group gaps into deliverable chunks; plan increments	Candidate work packages, Transition Architectures, Implementation & Migration Strategy
F · Migration Planning	Sequence and cost the work into a real plan	Implementation & Migration Plan, finalised Transition Architectures, cost/benefit & risk
G · Implementation Governance	Keep delivery compliant with the architecture	Architecture Contracts, compliance assessments, architecture oversight of projects
H · Architecture Change Management	Monitor, absorb change, decide when to iterate	Change requests, updated Architecture Repository, decision to start a new ADM cycle
Requirements Management	Manage requirements across all phases (continuous)	A live, prioritised requirements repository driving every phase

Baseline, target, gap — the phrase that repeats

Phases B, C, and D all follow the same rhythm: describe the baseline, describe the target, then do a gap analysis to find what must change. Those gaps become the raw material for the work packages in Phase E. In ArchiMate the gaps are literally modelled as Gap elements.

How ArchiMate maps to the ADM¶

This is where the two standards click together. Each ADM phase leans on a particular slice of the ArchiMate language, so the models you build become the phase's deliverables. The Open Group publishes this correspondence; here it is in Cadence Cycles terms:

ADM phase	Primary ArchiMate layer(s)	Representative views
Preliminary	Motivation (principles)	Principles catalogue; stakeholder/driver context
A · Vision	Motivation + Strategy	Stakeholder viewpoint, goal-realisation, a high-level layered "vision" view
B · Business	Business (+ Strategy capabilities)	Business cooperation (actors/roles), value streams, business process views; the capability map
C · Information Systems	Application	Application cooperation; application-usage (business ← app service); data models
D · Technology	Technology (+ Physical)	Technology & infrastructure-usage views; deployment of artifacts to nodes
E · Opportunities & Solutions	Implementation & Migration	Plateau (transition) views, capability increments, work-package structure
F · Migration Planning	Implementation & Migration	Migration/roadmap view: work packages sequenced across plateaus, Gap elements resolved
G · Implementation Governance	Implementation & Migration + Motivation	Architecture Contract; requirements-realisation compliance views
H · Change Management	Motivation (+ whole model)	Assessments/drivers of change re-evaluated against the live model
Requirements Management	Motivation	Requirements & constraints, traced (realisation/influence) to goals and to the layers that satisfy them

Read the table as a promise about the rest of this section: the Motivation and Strategy pages feed Phases A–B, the Business / Application / Technology pages feed Phases B–D, and the heat-maps, value-stream, and worked-example pages feed Phases E–F. The ArchiMate views aren't decoration around the method — they are the deliverables the method calls for.

Governance and the repository¶

Two supporting ideas keep the cycle honest:

The Architecture Repository is the memory of the practice. Baseline and target architectures, reference models, standards, and prior decisions live there so each ADM turn reuses rather than reinvents. For us, the committed cadence-cycles.archimate model plus these pages are that repository in miniature.
Architecture Governance is the enforcement. In Phase G an Architecture Contract binds delivery teams to the agreed target; compliance reviews check real systems against it; a Governance Log records the waivers and decisions. Without this step, the beautiful target architecture and the thing that actually ships quietly diverge.

So what — which decision this drives

The ADM is how an EA shop answers "can we start building yet, and against what?" You don't hand developers a vision (Phase A); you hand them a target Technology Architecture (Phase D) inside an Architecture Contract (Phase G), traceable back through capabilities and goals to the business case that paid for it. Every later page in this section produces one of those traceable links.