TOGAF 9.2 Framework

TOGAF — The Open Group Architecture Framework — is the most widely adopted enterprise architecture method in the world. Its enduring value is not the framework's taxonomy but its process: the Architecture Development Method (ADM), a repeatable, phased approach to designing, governing, and evolving an enterprise architecture.

TOGAF 9.2, released in 2018, refined the 9.1 standard with cleaner structure, updated artifacts, and better guidance. TOGAF 10 (2022) restructured the body of knowledge into a compact set of fundamentals plus a library of topic guides — but the ADM at the heart of TOGAF 9.2 remains the method most enterprises actually run. This page covers TOGAF 9.2 as the practical baseline.

This page walks the ADM phase by phase, explains the Enterprise Continuum and Architecture Repository that give the method its memory, and offers practical guidance on certification, tailoring, and common pitfalls.

The ADM is a circular, iterative process. It begins with a request for architecture work, defines the vision and scope, develops the four architecture domains, identifies opportunities and solutions, plans migration, governs implementation, and manages change — then feeds learnings back into the next cycle. The cyclical nature is deliberate: EA is never done; each pass deepens the repository and sharpens the target state.

Each phase has defined objectives, inputs, steps, and outputs. The discipline of the ADM is in treating these as real gates rather than ceremonial documentation. A phase skipped tends to resurface as a gap, risk, or rework in a later phase or a downstream project.

Phase A frames the engagement: who cares, what is in scope, what success looks like. The most valuable artifact from Phase A is the Statement of Architecture Work — a contract between the architecture team and the sponsor that prevents scope drift later.

Phases B, C, and D develop the four domains — business, data, application, and technology — first as a baseline (current state) and then a target state, with a gap analysis between them. The order matters: business architecture leads, because data, applications, and technology exist to serve capabilities and value streams. Developing technology architecture first inverts the relationship and produces a technology-led, business-detached design.

A common, pragmatic tailoring is to compress B/C/D into a single architecture-definition iteration for smaller scopes, then expand them when the enterprise needs full domain depth. TOGAF explicitly supports such tailoring; the method is a scaffold, not a straitjacket.

Phase E turns architecture into action by identifying candidate projects, reusable building blocks, and transition architectures — intermediate states between baseline and target that let the enterprise move incrementally. Phase F sequences those projects into a roadmap, factoring cost, benefit, risk, and dependency.

Phase G is where governance earns its keep. Each implementation project operates under an architecture contract specifying conformance requirements; the architecture function reviews deliverables for compliance. Without Phase G, the ADM produces architecture that is ignored; with it, the ADM produces architecture that is realised.

Phase H closes the loop, capturing change requests, monitoring the environment, and deciding whether to update, re-architect, or retire. This is what makes the repository living rather than historical.

The Enterprise Continuum is TOGAF's way of classifying architectures from the most generic to the most specific — from foundation architectures and common systems through to organisation-specific architectures. It frames how reusable assets accumulate over time, from industry patterns down to bespoke solutions.

The Architecture Repository is the practical counterpart: a structured store of all architecture artifacts — the architecture metamodel, the architecture capability, building blocks, reference models, standards, and governance logs. The repository is what allows an enterprise to reuse across projects, enforce standards, and answer questions quickly. A TOGAF practice without a living repository is performing the method but not capturing its value.

The Solutions Continuum mirrors this on the solutions side — from off-the-shelf products through to custom-built solutions — giving a vocabulary for make-vs-buy and reuse decisions.

The Open Group offers a recognised certification ladder: TOGAF Foundation (level 1), TOGAF Certified (level 2), and the TOGAF 9 Practitioner qualification introduced after the 9.2 update for practical application. TOGAF 10 introduced updated credentials aligned to the restructured body of knowledge.

Certification matters less as a credential and more as a shared vocabulary. A team where everyone uses Phase E, building block, and transition architecture to mean the same thing communicates far more efficiently than one relying on implicit, individual mental models.

The pragmatic path is to certify a core of architects and use internal enablement to spread the vocabulary to the wider technology organisation — including solution architects, project managers, and engineering leads who interact with the ADM without running it.

TOGAF's own guidance is emphatic that the ADM should be tailored to the organisation. Phases can be combined, iterated, or omitted where scope justifies it; the method explicitly anticipates this. The mistake is not tailoring — it is tailoring without intent, dropping phases to save time rather than because scope makes them unnecessary.

Common pitfalls include treating the ADM as a waterfall (it is iterative and cyclic), producing documents instead of decisions, skipping Phase G so architecture is never enforced, and letting the repository atrophy into an artifact graveyard. The antidote to all four is the same: anchor every phase to a decision or action that changes what the enterprise does next.