This guide is a complete, self-contained reference designed for TOGAF 9.x Foundation candidates and practicing architects. It distills the Togaf ADM into clear conceptual blocks, practical examples, actionable guidelines, and exam-focused tips.
The ADM is the heartbeat of TOGAF. It is a tested, repeatable, and iterative process for developing organization-specific Enterprise Architecture.
The ADM is structured as a cycle of phases, each with distinct objectives:
| Phase | Primary Objective |
|---|---|
| Preliminary Phase | Prepare the organization: customize TOGAF, define Architecture Principles, establish the Architecture Capability. |
| Phase A: Architecture Vision | Define scope, identify stakeholders, create the Architecture Vision, and obtain approval (Statement of Architecture Work). |
| Phase B: Business Architecture | Develop the Baseline and Target Business Architectures and identify gaps. |
| Phase C: Information Systems Architectures | Develop Data and Application Architectures (Baseline, Target, and Gap Analysis). |
| Phase D: Technology Architecture | Develop the Technology Architecture (Baseline, Target, and Gap Analysis). |
| Phase E: Opportunities & Solutions | Identify implementation projects, group them into work packages, and determine Transition Architectures. |
| Phase F: Migration Planning | Develop a detailed Implementation and Migration Plan. |
| Phase G: Implementation Governance | Provide architectural oversight during implementation; ensure compliance via Architecture Contracts. |
| Phase H: Architecture Change Management | Monitor the architecture and manage changes to ensure it continues to deliver business value. |
| Requirements Management | Central, ongoing process that identifies, stores, and feeds requirements into/out of all ADM phases. |
Iterative Nature: The ADM supports iteration at three levels: cycling around the entire cycle, iterating between phases (e.g., returning to Phase B after Phase D), and cycling within a single phase to elaborate content.
Requirements Management Placement: Visually centered in the ADM diagram because it drives and validates every phase. It does not dispose of or prioritize requirements itself; it manages their flow.
Always validate outputs against original requirements at each iteration.
Consider assets from previous iterations and external marketplaces at every phase.
The ADM does not dictate scope; the organization must define it based on value, resources, and feasibility.
TOGAF uses a structured model (the Architecture Content Framework) to consistently present architectural work products.
| Term | Definition | Key Characteristics |
|---|---|---|
| Deliverable | Contractually specified work product, formally reviewed, agreed, and signed off by stakeholders. | Represents project output. Often archived or transitioned into the Architecture Repository as a reference model or snapshot. |
| Artifact | Architectural work product describing an aspect of the architecture. | Classified as Catalogs (lists), Matrices (relationships), or Diagrams (visuals). A deliverable contains many artifacts. |
| Building Block | A potentially reusable component of business, IT, or architectural capability. | Defined at varying detail levels. Can be Architecture Building Blocks (ABBs) or Solution Building Blocks (SBBs). |
Deliverables → contain → Artifacts → represent → Building Blocks
Artifact Types: Requirements Catalog (catalog), Business Interaction Matrix (matrix), Use-Case Diagram (diagram).
ABB vs SBB:
ABB: “Customer Relationship Management capability” (defines what functionality is needed).
SBB: “Salesforce CRM v2024” or “Custom-built Java module” (defines how it’s implemented).
ABBs shape and direct the development of SBBs.
Building blocks should have published, stable interfaces to ensure interoperability.
Specification should be loosely coupled to implementation to allow multiple realization options.
The Enterprise Continuum provides a conceptual “view” of how architectural assets evolve from generic to organization-specific.
It comprises two complementary continuums:
Architecture Continuum: Contains reusable architecture assets (ABBs). Evolves from abstract rules/models to fully expressed Organization-Specific Architectures.
Solutions Continuum: Contains reusable solution assets (SBBs). Represents the actual implementations, products, and services that realize the architectures.
Foundation → Common Systems → Industry → Organization-Specific
Left: Generic, reusable, standards-driven.
Right: Specific, tailored, implementation-ready.
Architecture Continuum: TOGAF Technical Reference Model (TRM) → Security Architecture Framework → Healthcare Data Architecture → Acme Corp’s Internal Data Architecture.
Solutions Continuum: Linux OS/Java (Foundation) → Oracle DB/Microsoft Azure (Common Systems) → Epic EHR System (Industry) → Acme Corp’s Custom Patient Portal (Org-Specific).
Use the Continuum to promote reuse and avoid reinventing the wheel.
When moving right, leverage existing assets. When gaps appear, pass requirements left to create new reusable assets.
The Repository is the physical implementation of the Enterprise Continuum. It stores, classifies, and manages all architectural outputs.
| Component | Purpose |
|---|---|
| Architecture Metamodel | Organizationally tailored application of the framework; defines how architecture content is structured. |
| Architecture Capability | Parameters, structures, and processes that govern the repository. |
| Architecture Landscape | Views of assets in use/planned at specific points in time. Divided into three levels: Strategic, Segment, and Capability Architectures. |
| Standards Information Base (SIB) | Captures standards new architectures must comply with (industry standards, selected products, shared services). |
| Reference Library | Guidelines, templates, patterns, and reference materials to accelerate new architectures. |
| Governance Log | Record of all governance activities across the enterprise. |
| Architecture Requirements Repository | View of all authorized architecture requirements agreed upon with the Architecture Board. |
| Solutions Landscape | Architectural representation of SBBs planned or deployed to support the Architecture Landscape. |
The repository grows with each ADM iteration. Early cycles are hardest due to scarce reusable assets; later cycles benefit from accumulated content.
Maintain strict governance over repository updates to ensure integrity and trust.
Enterprise Architecture must be run like a business unit, not just a theoretical exercise.
Architecture Capability Framework: Provides guidelines, templates, and processes to establish an architecture function.
Operational Capabilities Required: Financial Management, Performance Management, Service Management, Risk Management, Resource Management, Communications & Stakeholder Management, Quality Management, Supplier Management, Configuration Management, Environment Management.
Central Element: Effective Architecture Governance to control and align all architecturally significant activities.
Increased transparency & accountability
Controlled risk management
Maximized reuse of existing components
Proactive monitoring & feedback loops
Greater shareholder value & regulatory compliance
Seamless integration with existing corporate processes
Secure executive sponsorship early.
Define clear boundaries and decision rights.
Treat the EA practice as a service provider to the business, with measurable KPIs and SLAs.
TOGAF is deliberately framework-agnostic and designed to complement, not replace, existing methodologies.
TOGAF focuses on the method (ADM) and provides a flexible content framework for deliverables.
Other frameworks often focus heavily on specific deliverables but are silent on the method to produce them.
TOGAF can be seamlessly integrated with: ITIL®, CMMI®, COBIT®, PRINCE2®, PMBOK®, MSP®, and domain-specific frameworks.
Use PRINCE2 for project management governance while applying the ADM for architectural development.
Use COBIT for IT governance controls, mapping TOGAF Phase G compliance checks to COBIT processes.
Always tailor TOGAF to fit your organization’s existing processes, culture, and maturity level.
Replace or extend TOGAF’s generic deliverables with framework-specific ones if required by industry or regulatory mandates.
| Area | Guideline |
|---|---|
| Scoping | Define breadth, depth, time period, and architecture domains before starting. Focus on what creates business value. |
| Iteration | Expect to revisit phases. Use cycling to refine content, validate against requirements, and adjust scope/detail. |
| Reuse Strategy | Start left in the Continuum. Only build custom assets when no suitable Foundation/Industry models exist. |
| Governance | Embed compliance checks in Phase G. Use the Governance Log to track decisions, dispensations, and audits. |
| Repository Management | Version all outputs. Archive deliverables as snapshots or reference models. Keep the SIB updated with current standards. |
ADM Phase Order: Memorize the sequence. Remember Phase A is the initial phase of a cycle, while the Preliminary Phase is preparatory and not part of the iterative cycle itself.
Deliverable vs Artifact vs Building Block:
Deliverable = Contractual & signed off
Artifact = Catalog/Matrix/Diagram
ABB = What functionality is needed
SBB = How it’s implemented (appears first in Phase E)
Continuum Direction: Left = Generic/Abstract/Foundation. Right = Specific/Concrete/Organization. Architecture Continuum = ABBs. Solutions Continuum = SBBs.
Repository Components: If a question asks where “templates, patterns, and guidelines” are stored → Reference Library. If it asks about “standards new architectures must comply with” → SIB.
Requirements Management: It is central and continuous. It does not prioritize requirements; it manages their flow into and out of phases.
Capability vs Framework: TOGAF provides a framework. How you establish and run it is the Architecture Capability. Treat it as an operational business unit.
Elimination Strategy in Exams: Watch for distractors like “Phase C is Requirements Architecture” (false, it’s Information Systems). Remember “Phases are not mandatory; tailoring may omit or modify them.”
Can I list all ADM phases and state their high-level purpose?
Can I distinguish between Deliverables, Artifacts, and Building Blocks (ABB vs SBB)?
Do I understand the left-to-right evolution of the Enterprise Continuum?
Can I name the 8 core components of the Architecture Repository?
Do I know the operational capabilities required to run an EA practice?
Can I explain how TOGAF integrates with ITIL, PRINCE2, COBIT, etc.?
Am I clear on where Requirements Management sits and what it does?
TOGAF ADM lays the foundational architecture for everything else in TOGAF. Mastering the ADM cycle, understanding how work products are structured (deliverables → artifacts → building blocks), grasping the reuse philosophy of the Enterprise Continuum, and recognizing the operational nature of an Architecture Capability will give you both exam confidence and real-world architectural clarity. Use this guide as a reference while practicing the chapter’s test questions, and cross-reference with the official TOGAF 9.x documentation for deeper study.
