TL;DR
The TOGAF ADM (Architecture Development Method) is the core method for developing and managing enterprise architecture. It is iterative, tailorable, and centered on requirements management. In practice, it helps teams move from baseline to target architecture in a governed way.
BDAT mapping in ADM: B = Phase B, D + A = Phase C, T = Phase D.
What is ADM?
The Architecture Development Method (ADM) is TOGAF’s method for developing and managing the lifecycle of enterprise architecture.
If your question is “How do we actually build and evolve EA?”, ADM is the answer in TOGAF.
It gives a repeatable way to:
- prepare architecture capability
- define architecture from vision to target state
- plan migration from baseline to target
- govern implementation
- manage ongoing change
Why ADM matters
ADM helps organizations transform in a controlled way instead of through disconnected projects.
It gives enough structure to reduce risk and improve traceability, while still allowing tailoring for enterprise context.
ADM at a glance
ADM has 10 phases:
- Preliminary Phase (before the cycle)
- Phases A-H (main development cycle)
- Requirements Management (continuous, at the center)
flowchart TD P["Preliminary"] subgraph CYCLE["ADM Cycle (iterative)"] direction LR A["A: Architecture Vision"] --> B["B: Business Architecture"] --> C["C: Information Systems Architectures<br/>(Data + Application)"] --> D["D: Technology Architecture"] --> E["E: Opportunities and Solutions"] --> F["F: Migration Planning"] --> G["G: Implementation Governance"] --> H["H: Architecture Change Management"] --> A end R["Requirements Management<br/>(continuous across all phases)"] P --> A R -. governs and updates requirements for .-> CYCLE
What each phase does (simple)
| Phase | Main purpose |
|---|---|
| Preliminary | Establish EA capability, governance, principles, and tailored approach |
| A: Architecture Vision | Define scope, stakeholders, and high-level architecture vision; secure approval to proceed |
| B: Business Architecture | Define baseline/target business architecture and gaps |
| C: Information Systems Architectures | Define baseline/target data + application architectures and gaps |
| D: Technology Architecture | Define baseline/target technology architecture and gaps |
| E: Opportunities and Solutions | Identify solution approach, work packages, and delivery vehicles |
| F: Migration Planning | Prioritize and finalize implementation/migration plan |
| G: Implementation Governance | Ensure implementation conforms to architecture direction |
| H: Architecture Change Management | Manage change after deployment and decide when to trigger a new ADM cycle |
| Requirements Management | Manage architecture requirements continuously across all phases |
Preliminary Phase: what changes here
The Preliminary Phase is where the organization gets ready to do architecture work properly.
Typical outcomes:
- EA operating model and governance setup
- roles, responsibilities, and architecture board patterns
- tailored TOGAF method for the enterprise context
- architecture principles used as guardrails
Without this foundation, later phases usually become inconsistent.
ADM is iterative, not strict waterfall
ADM is often shown as a cycle for clarity, but execution is not rigid.
Important practical points:
- phases can iterate
- outputs can be refined in later phases
- sequence can be adapted based on governance and context
- requirements changes can trigger revisits to earlier work
ADM is really a reference model for what must be addressed, not a one-size-fits-all process script.
What gets produced during ADM
Each phase produces outputs (artifacts and deliverables).
These outputs evolve as the cycle progresses.
Common examples:
- Architecture Vision
- Architecture Definition content across business, data, application, and technology
- Architecture Roadmap and Implementation/Migration Plan
- governance and compliance outputs during implementation
In practice, architecture documentation starts broad, then becomes more detailed and actionable across phases.
Quick memory aid for core architecture phases
For architecture definition phases, remember BDAT:
- Business
- Data
- Application
- Technology
That maps to Phase B, Phase C (Data + Application), and Phase D.
Exam note
- ADM is the core method in TOGAF for developing and managing enterprise architecture.
- It includes Preliminary, A-H, and a continuous Requirements Management process.
- Phase C covers both Data and Application architectures together.
- ADM is iterative and tailorable; it is not a mandatory waterfall sequence.
- Requirements changes are governed and propagated across all phases.