The TOGAF Architecture Development Method (ADM) is a repeatable cycle for working out where an organisation’s systems need to go, and how to get there safely.
What it is
TOGAF is an enterprise architecture standard published by The Open Group; the current version is the TOGAF Standard, 10th Edition. At its core is the Architecture Development Method: a set of phases that take an architecture effort from an initial idea, through design, to planning and overseeing the change.
The ADM is a method, not a template. It describes the questions to answer and the kinds of output that help answer them, and it expects to be adapted to the organisation and the problem in hand. It is also iterative: phases can be revisited as understanding improves, and the whole cycle can be repeated as the business changes.
Key parts
The ADM has a preliminary phase, eight lettered phases, and requirements management running throughout.
| Phase | Purpose |
|---|---|
| Preliminary | Prepare the ground: scope, principles, who makes decisions, and how the method will be tailored |
| A – Architecture Vision | Agree the problem, stakeholders, drivers and goals, and a high-level picture of the outcome |
| B – Business Architecture | Describe the business today and as intended: capabilities, processes and organisation |
| C – Information Systems Architectures | Do the same for data and applications |
| D – Technology Architecture | Do the same for platforms and infrastructure |
| E – Opportunities and Solutions | Compare the options for closing the gaps, including build vs. buy, and group the work |
| F – Migration Planning | Sequence the change into a roadmap of transition architectures and work packages |
| G – Implementation Governance | Keep delivery in line with the agreed architecture |
| H – Architecture Change Management | Watch for changes that affect the architecture, and decide when a new cycle is needed |
| Requirements Management | Capture and track requirements as they emerge and change, throughout every phase |
The phases fall naturally into four groups, which TOGAF calls iteration cycles. Each group can be repeated on its own before moving on, for example several passes through B to D while the target architecture settles.
In practice
Applying every phase in full is rarely the right answer, especially outside large enterprises. Tailoring the ADM well means putting the effort where the risk is:
- Match the depth to the problem. A system replacement may need little business architecture but careful migration planning. A new product line may be the reverse.
- Keep outputs proportionate. A one-page vision, a short list of principles and a few well-chosen diagrams can do the job of much larger documents.
- Iterate rather than complete. It is normal to return to earlier phases as gaps and options become clearer.
- Use it as a checklist. Even when the full method is too heavy, the phases are a useful prompt for questions that might otherwise be missed, such as who decides, what happens during the transition, and how the change will be governed.
Where it appears
- Architecture Glossary – definitions of ADM terms such as plateau, transition architecture and gap analysis.
- Architecture in Practice case studies show the ADM tailored to specific business problems.
Further reading
- The TOGAF Standard – The Open Group’s official home for the standard, including the full ADM.
Last reviewed: November 2026
TOGAF® is a registered trademark of The Open Group.