TOGAF
Handbook
A comprehensive reference for enterprise architects, IT strategists, and business leaders — covering the TOGAF standard, the Architecture Development Method (ADM), key components, governance, and practical guidance for real-world adoption.
What Is TOGAF?
TOGAF (The Open Group Architecture Framework) is a globally recognised framework for Enterprise Architecture (EA). It provides a standardised vocabulary, process model, and set of tools that organisations use to plan, design, and govern their business and IT landscape as a coherent whole.
At its core, TOGAF gives organisations a repeatable method for developing, managing, and using an enterprise architecture — ensuring that technology investments align with business strategy and that change is delivered in a structured, low-risk way.
TOGAF is a framework and methodology — a body of knowledge. It does not prescribe a specific software tool; organisations choose their own modelling tools (Archi, Sparx EA, LeanIX) to implement it.
Maintained by The Open Group, a neutral consortium. It is not owned by any technology vendor, making it applicable regardless of your technology stack or cloud provider.
Used by the majority of Fortune 500 companies, government agencies, and large enterprises worldwide. TOGAF certification is one of the most sought-after EA credentials globally.
What Problem Does It Solve?
- IT projects misaligned with business goals
- Duplicated systems and shadow IT proliferation
- No shared vocabulary between business and IT teams
- Inability to assess the impact of organisational change
- Technical debt accumulation with no visibility
- Costly, high-risk large-scale transformations
- Technology decisions traceable to business strategy
- Consolidated, rationalised application portfolios
- Shared language between CXO, IT, and operations
- Structured impact analysis before making changes
- Proactive technical debt management and roadmaps
- Reduced risk and faster, more predictable delivery
Purpose & Goals
TOGAF exists to answer one fundamental question: How do we ensure that every technology decision serves the long-term goals of the organisation? Its purpose spans strategic alignment, operational efficiency, and change management.
Bridge the gap between business strategy and IT execution. Ensure every system, platform, and capability investment can be traced back to a business objective or outcome.
Establish a common language and approach across the enterprise. Prevent each department or project from developing siloed architectures incompatible with the rest of the organisation.
Provide a single source of truth — the Architecture Repository — so that decisions about change, procurement, or transformation are grounded in accurate, current data about the enterprise landscape.
Identify inter-dependencies, gaps, and conflicts before implementing change. A documented architecture lets you model the impact of decisions before spending a single dollar.
Build a catalogue of reusable building blocks — patterns, services, and components — so future projects can leverage existing assets rather than rebuilding from scratch.
Define who approves architectural decisions, how compliance is checked, and how deviations are handled. Prevent ungoverned proliferation of technology that creates cost and risk.
History & Versions
| Year | Version | Milestone |
|---|---|---|
| 1995 | TOGAF 1 | First release. Based on the US Department of Defense's TAFIM (Technical Architecture Framework for Information Management). |
| 1996–2001 | TOGAF 2–7 | Iterative refinement. ADM established as the central process. The Open Group Architecture Forum driven by industry contributors. |
| 2002 | TOGAF 8 | "Enterprise Edition" — significant expansion. Enterprise Continuum introduced. Broadened from IT to full enterprise scope. |
| 2009 | TOGAF 9 | Major overhaul. Architecture Content Framework, Architecture Repository, Architecture Capability Framework, and governance guidance formalised. Became the industry standard. |
| 2011 | TOGAF 9.1 | Clarifications and bug fixes. No structural change. The version most certified professionals hold credentials in. |
| 2018 | TOGAF 9.2 | Improved guidance on Agile architecture, business architecture, and security. Content restructured for clarity. Digital transformation coverage added. |
| 2022 | TOGAF Standard v10 | Current version. Repackaged into a modular "Series" format. Core standard separated from guidance documents for easier adoption. Agile, DevOps, and cloud-native patterns incorporated. |
When To Use TOGAF
TOGAF is a heavyweight framework appropriate for large, complex organisations undergoing strategic change. It is not the right tool for every situation — understanding when to apply it (and when not to) is as important as knowing how.
- Undergoing digital transformation or major platform migration
- Mergers, acquisitions, or post-merger IT integration
- Government or regulated industry mandating architecture governance
- Complex multi-department, multi-system landscapes need rationalisation
- Business strategy is repeatedly undermined by technical constraints
- Large-scale ERP, CRM, or core platform replacements
- Standing up or maturing an Enterprise Architecture practice
- Cloud migration strategy across hundreds of applications
- Small organisations (<200 people) with a simple IT landscape
- Startups moving at speed — overhead outweighs benefit
- Projects with very narrow, well-defined scope (feature-level)
- Fully Agile product teams doing continuous incremental delivery
- No executive sponsorship or architecture team to sustain it
- Organisations seeking only solution or application architecture
- Teams that need lightweight governance (consider Scaled Agile / SAFe instead)
Scale of Adoption
TOGAF does not need to be adopted all-or-nothing. Most organisations start with a subset:
Adopt the ADM and Architecture Repository. Focus on documenting the current state and defining a target architecture for a single major initiative.
Add governance through an Architecture Review Board (ARB). Define principles, standards, and a formal compliance process for new projects.
Mature capability with full stakeholder engagement, strategic roadmaps, Architecture Capability Framework, and continuous architecture lifecycle.
Framework Structure
TOGAF is not a single monolithic document — it is structured around four interrelated components that together define how enterprise architecture is developed and governed.
The heart of TOGAF. A cyclical, phase-based process for developing architecture. It provides step-by-step guidance on how to create a baseline architecture, define a target architecture, and plan the transition between them.
- Iterative and cyclical — not waterfall
- Ten phases from Preliminary through ADM Requirements Management
- Can be adapted to specific organisational needs
Defines what gets produced. A structured classification of architectural work products — deliverables, artefacts, and building blocks. Ensures consistency in what architecture outputs look like.
- Deliverables: contractual outputs (e.g. Architecture Definition Document)
- Artefacts: diagrams, catalogs, matrices
- Building Blocks: reusable components (ABBs and SBBs)
A classification system and storage mechanism for architectural assets — from generic, reusable patterns (Foundation Architecture) through to organisation-specific assets (Organisation-Specific Architecture).
- Architecture Repository stores all architectural assets
- Reference Library, Standards Information Base, Solution Landscape
- Enables reuse and prevents reinventing the wheel
Defines how to establish and run an architecture function within an organisation. Covers roles, skills, governance structures, processes, and the maturity model for an architecture practice.
- Architecture Board, Review processes, Compliance
- EA maturity models and skills framework
- Architecture contracts and principles
The ADM Cycle
The Architecture Development Method (ADM) is the central process of TOGAF. It is a cycle of phases that together describe how to plan, create, govern, and evolve enterprise architecture. Critically, it is iterative — you do not complete it once and shelve it. Architecture is continuously revisited as the business and technology landscape evolves.
The ADM can be iterated at three levels: the overall cycle (repeating as the business changes), within a phase (refining outputs), and across phases (returning to an earlier phase when new information emerges).
TOGAF explicitly supports adapting the ADM. Phases can be combined, re-ordered, or run concurrently. Agile organisations often run phases in shorter sprints with lighter deliverables.
ADM Phases
Key Deliverables & Artefacts
The Architecture Content Framework classifies all TOGAF outputs into three types. Understanding the distinction helps teams know what level of formality and approval is required for each output.
Formally reviewed and signed-off outputs from an ADM phase. These are contractual commitments that must be approved before the next phase begins.
- Architecture Definition Document
- Architecture Requirements Specification
- Statement of Architecture Work
- Architecture Contract
- Architecture Roadmap
Architectural work products — diagrams, lists, matrices — that are components within a deliverable. They describe an architecture from a specific viewpoint.
- Catalogs (e.g. Application Catalogue)
- Matrices (e.g. Application-Data Matrix)
- Diagrams (e.g. Business Process Diagram)
- Capability Maps
- Stakeholder Maps
Reusable components of business, IT, or architectural capability. Two types — ABBs and SBBs — form the basis of the Enterprise Continuum.
- ABBs — Architecture Building Blocks (capability definitions)
- SBBs — Solution Building Blocks (product/component implementations)
- Example ABB: "Customer Identity Service"
- Example SBB: "Azure Active Directory B2C"
Core Deliverable Summary
| Deliverable | Phase | Purpose |
|---|---|---|
| Architecture Vision | A | High-level summary of stakeholder concerns and the end-state vision for the architecture engagement |
| Statement of Architecture Work | A | Defines the scope, schedule, constraints, and resources for an architecture engagement — a formal contract to proceed |
| Architecture Definition Document | B/C/D | The primary deliverable containing baseline and target architectures across all four domains (Business, Data, Application, Technology) |
| Architecture Requirements Specification | B/C/D | Quantified and measurable requirements that the architecture must satisfy; drives conformance testing |
| Architecture Roadmap | E/F | Sequenced work packages and projects that transition the enterprise from baseline to target state |
| Architecture Contract | G | Formal agreement between the architecture team and project delivery team on what will be built and how compliance is measured |
| Compliance Assessment | G | Review of a project's architecture against the approved target architecture and standards |
| Implementation & Migration Plan | F | Detailed transition plan showing how work packages map to programmes, projects, timelines, and funding |
Architecture Domains (BDAT)
TOGAF organises enterprise architecture into four domains, often remembered by the acronym BDAT. Each layer informs the one below it — business requirements drive data needs, data needs drive application choices, and applications drive technology selection.
Also called "AS-IS". Documents the current state of the enterprise across all four domains. Essential starting point — you cannot plan a transformation if you do not know where you are starting from.
Also called "TO-BE". Defines the desired future state across all four domains. Aligned directly with business strategy and goals. The gap between baseline and target defines the transformation scope.
Architecture Repository
The Architecture Repository is the structured storage system for all TOGAF outputs and supporting assets. It is supported by the Enterprise Continuum — a classification system that organises assets from generic, reusable patterns through to organisation-specific implementations.
Stores the current suite of architectures — strategic (long-term direction), segment (specific domains or divisions), and capability (specific capabilities like security or cloud). Three levels of architecture abstraction.
A repository of approved technology standards — vendor products, technology versions, open standards — that projects must comply with. The SIB prevents ungoverned technology sprawl.
Pre-existing architectural patterns, reference architectures, and guidance documents. Includes TOGAF's own reference models (TRM and III-RM) and any organisation-specific templates.
A portfolio view of implemented solutions (SBBs) and what capabilities they deliver. Used for impact analysis, application portfolio management, and identifying decommission candidates.
Records of architecture decisions, ARB minutes, waivers, compliance assessments, and change requests. Provides an audit trail of all governance activity over time.
The framework, processes, roles, skills, and maturity models that define how the architecture function operates. Stored here so the EA practice itself is documented and improvable.