TOGAF is a framework, not a religion. The Architecture Development Method (ADM) provides a structured cycle for enterprise architecture work — but applying it rigidly in modern agile delivery contexts creates more bureaucracy than value. After five engagements using TOGAF, here's our calibrated view of which phases earn their keep.
What We Always Keep
Phase A (Architecture Vision) is non-negotiable. Aligning stakeholders on what architecture work will deliver and why before any technical work begins prevents the most common failure mode: architects designing things nobody asked for. The Architecture Vision document, kept to two pages, becomes the engagement charter.
Phase B (Business Architecture) — specifically capability mapping — is essential for large transformations. You cannot design a target-state IT architecture without understanding the business capabilities it needs to support. We run this as a facilitated workshop rather than a lengthy documentation exercise.
Phase H (Architecture Change Management) is frequently skipped and consistently regretted. Architecture without a change governance model decays — new projects ignore it, exceptions accumulate, and the architecture becomes fiction within 18 months.
What We Streamline
Phases C and D (Information Systems and Technology Architecture) are where TOGAF's documentation requirements balloon. We apply these phases selectively, producing architecture artefacts only where the decision complexity justifies them. A C4 Container diagram and three ADRs often replace what TOGAF would specify as dozens of ArchiMate views and deliverables.
- Always run Phase A — Architecture Vision alignment prevents wasted effort
- Capability mapping (Phase B) is essential for transformation context
- Never skip Phase H — architecture governance is what makes architecture persist
- Use C4 + ADRs instead of full ArchiMate deliverables for most phases