TOGAF and the Architecture Development Method

The structure of the TOGAF Standard, the ADM phases, and how to tailor it rather than follow it literally.

TOGAF in context

TOGAF (The Open Group Architecture Framework) is the most widely used enterprise architecture framework, and the basis of the most widely held EA certification. It’s vendor-neutral and maintained by The Open Group. The current version is the TOGAF Standard, 10th Edition, released in 2022.

Two things to keep in mind:

TOGAF is a toolkit, not a process to follow literally. The standard itself says it should be tailored. Most successful EA practices use a small, adapted subset.
Knowing TOGAF well is still worth it, even if you never run a “TOGAF project.” It gives you a shared vocabulary with other architects, a checklist of things you might be forgetting, and the certification.

How the standard is organized

The 10th Edition splits into two parts:

Fundamental Content: the stable core. It covers introduction and core concepts, the ADM, ADM techniques, applying the ADM, architecture content, and EA capability and governance.
Series Guides: practical guidance on specific topics (business architecture, agile, security, digital, and more) that can be updated more often than the core.

Exam note: Know the split between Fundamental Content and Series Guides, and that the 10th Edition was designed to be more modular than 9.2, so guidance can evolve without changing the core standard.

The ADM at a glance

The Architecture Development Method (ADM) is TOGAF’s core: an iterative cycle for developing and managing enterprise architecture.

                     ┌──────────────┐
                     │ Preliminary  │
                     └──────┬───────┘
                            ▼
               ┌──► A. Architecture Vision ──┐
               │                             ▼
     H. Architecture                    B. Business
     Change Management                  Architecture
               ▲                             ▼
     G. Implementation  ┌──────────────┐  C. Information Systems
        Governance      │ Requirements │     Architectures
               ▲        │  Management  │     ▼
     F. Migration       └──────────────┘  D. Technology
        Planning                          Architecture
               ▲                             │
               └── E. Opportunities ◄────────┘
                      and Solutions

The phases group naturally:

Group	Phases	Question answered
Getting ready	Preliminary, A	How will we do architecture, and what’s this piece of work about?
Defining the architecture	B, C, D	What does the target look like in each domain, and what’s the gap?
Planning the change	E, F	How do we get there, in what increments?
Making it real and keeping it current	G, H	Is delivery following the architecture? What happens when things change?

The phases

For each phase: what it’s for, the outputs worth remembering, and how it played out at Quillfeather, where your task is the board’s request for a technology plan for EU expansion.

Preliminary: prepare the organization

Purpose: Decide how the organization will do architecture. Define the EA capability: scope, organizational model, principles, governance, tools, and how TOGAF will be tailored.

Key outputs: Organizational Model for EA, Tailored Architecture Framework, Architecture Principles, initial Architecture Repository, Request for Architecture Work (usually from the sponsor).

At Quillfeather: This was the first two weeks of the role. You agreed with the CTO that EA would be federated, that a few principles would be published early, and that decisions would be recorded as ADRs. The Request for Architecture Work was the CTO’s email: “The board wants a credible technology plan for EU expansion by end of next quarter.”

Phase A: Architecture Vision

Purpose: Set the scope, identify stakeholders and their concerns, and create a high-level, aspirational vision of the target. Get approval to proceed.

Key outputs: Statement of Architecture Work (scope, approach, plan, approved by the sponsor), Architecture Vision, Communications Plan, Capability Assessment, refined principles and business goals.

At Quillfeather: Your vision was a two-page document and one diagram: “One Quillfeather platform serving UK and EU customers, with a single customer identity, EU data residency, and local payment methods.” Scope was explicitly limited to the expansion, not to every problem in the estate. The CTO and CFO signed off the Statement of Architecture Work.

Phase B: Business Architecture

Purpose: Describe the baseline and target business architecture (capabilities, value streams, organization, processes) and the gaps between them.

Key outputs: Draft Architecture Definition Document and Architecture Requirements Specification (business sections), candidate roadmap components.

At Quillfeather: The capability map and “Let a Property” value stream from module 4. Gaps identified included EU tenant screening, SEPA payment collection, multilingual tenant communication, and GDPR-grade consent management.

Phase C: Information Systems Architectures

Purpose: Baseline, target, and gaps for data architecture (major data entities, ownership, flows) and application architecture (applications and how they interact).

Key outputs: Data and application sections of the Architecture Definition Document and Requirements Specification, more candidate roadmap components.

At Quillfeather: Data architecture exposed the core problem: customer and tenant data in four systems with no clear owner. The target defined a single customer master and an EU data store. Application architecture rated each application against the target. The three notification services would consolidate into one, and PayNest would be extended for SEPA rather than rebuilt.

Phase D: Technology Architecture

Purpose: Baseline, target, and gaps for the technology that supports the applications: infrastructure, platforms, networks, hosting.

Key outputs: Technology sections of the Architecture Definition Document and Requirements Specification, more candidate roadmap components.

At Quillfeather: The target was an AWS EU region for customer data, with FixIt Pro migrating from Azure to AWS over time (not as a prerequisite for launch). Identity would consolidate on a single identity provider.

Exam note: Phases B, C, and D share a common set of steps: select reference models, viewpoints, and tools; develop the baseline; develop the target; perform gap analysis; define candidate roadmap components; resolve impacts across the landscape; conduct a formal stakeholder review; finalize; and create the Architecture Definition Document.

Phase E: Opportunities and Solutions

Purpose: Consolidate gaps from B–D into work packages. Decide on the approach (build, buy, reuse) and whether an incremental approach with Transition Architectures is needed. Create the first complete Architecture Roadmap.

Key outputs: Initial complete Architecture Roadmap, Transition Architectures, initial Implementation and Migration Plan.

At Quillfeather: Twenty-three gaps consolidated into seven work packages. You defined two Transition Architectures: T1 “Launch-ready” (EU data residency, SEPA, consent management, single sign-on for core and FixIt Pro) and T2 “One platform” (single customer master, notification consolidation, FixIt Pro migrated to AWS).

Phase F: Migration Planning

Purpose: Finalize the roadmap and the Implementation and Migration Plan: sequence, cost, value, and risk of each work package, coordinated with the organization’s portfolio and budgeting.

Key outputs: Finalized Architecture Roadmap, Implementation and Migration Plan, Architecture Definition Document, Implementation Governance Model.

At Quillfeather: You worked with the CFO and engineering directors to cost each work package and fit them into quarterly planning. That turned the vision into something the board could fund: T1 in three quarters, T2 over the following year.

Phase G: Implementation Governance

Purpose: Make sure delivery conforms to the target architecture, through Architecture Contracts and compliance reviews, while handling real-world changes sensibly.

Key outputs: Architecture Contracts, Compliance Assessments, Change Requests, implemented solutions.

At Quillfeather: No heavyweight contracts. Each work package had a one-page “architecture brief” (outcome, constraints, relevant principles and ADRs) agreed with its delivery lead, plus a fortnightly architecture forum for issues. When the identity team wanted to use a different provider for FixIt Pro, it came to the forum, was rejected with reasons, and was recorded.

Phase H: Architecture Change Management

Purpose: Keep the architecture current as business and technology change. Decide whether changes can be absorbed, need updates to the architecture, or trigger a new ADM cycle.

Key outputs: Architecture updates, Change Requests, new Requests for Architecture Work.

At Quillfeather: Six months in, the CEO announced a partnership with a German insurer to offer tenant insurance, a new capability. That was too big to absorb, so it became a new Request for Architecture Work and a new, smaller ADM cycle.

Requirements Management: at the center

Purpose: Capture, store, and manage architecture requirements throughout the cycle. Every phase feeds requirements in and takes requirements out. It’s a continuous process, not a phase you pass through once.

Key outputs: Architecture Requirements Specification updates, Requirements Impact Assessment.

At Quillfeather: A shared, versioned requirements list linked to work packages. When German data-protection guidance turned out stricter than expected, the Requirements Impact Assessment showed which work packages it affected.

Key deliverables summary

Exam note: Know which phase first creates and which finalizes the key deliverables.

Deliverable	Created / finalized in
Request for Architecture Work	Input to Phase A (often from Preliminary or the sponsor)
Statement of Architecture Work	Phase A
Architecture Vision	Phase A
Architecture Definition Document	Drafted in B–D, finalized in F
Architecture Requirements Specification	Drafted in B–D, updated throughout
Architecture Roadmap	Candidate components in B–D, first complete version in E, finalized in F
Transition Architectures	Phase E (refined in F)
Implementation and Migration Plan	Initial in E, finalized in F
Architecture Contract	Phase G
Compliance Assessment	Phase G
Requirements Impact Assessment	Requirements Management

Iteration and scope

The ADM diagram looks like a waterfall, but it isn’t meant to be run as one. TOGAF describes four kinds of iteration:

Iteration	Phases	What cycles
Architecture Capability	Preliminary, A	Establishing or adjusting the EA capability itself
Architecture Development	B, C, D	Refining the architecture definition across domains
Transition Planning	E, F	Refining the roadmap and migration plan
Architecture Governance	G, H	Overseeing implementation and change

You can also iterate across the whole cycle and run several ADM cycles at different levels at the same time.

Scoping the work

TOGAF suggests scoping each piece of architecture work along four dimensions:

Breadth: which parts of the enterprise are in scope
Depth: how much detail is needed
Time period: how far ahead the target looks
Architecture domains: which of business, data, application, and technology are involved

TOGAF also describes architecture at different levels: strategic (long-term, enterprise-wide direction), segment (a portfolio or major area), and capability (a specific capability increment). At Quillfeather, the EU expansion was roughly segment-level work.

Tailoring for a scaling organization

Running every phase and producing every deliverable would take a scaling company longer than the strategy allows. A pragmatic tailoring:

Formal TOGAF	Lightweight version
Preliminary phase	A one-page “how we do architecture” note plus initial principles
Statement of Architecture Work	A one-page brief signed off by email
Architecture Definition Document	A living wiki page per initiative with key diagrams and decisions
B, C, D as separate phases	One combined workshop series, by domain
Architecture Contracts	Architecture briefs and ADRs
Architecture Board	A fortnightly architecture forum with clear decision rights

What to keep even when you cut everything else: clear scope and stakeholders (A), explicit baseline-to-target gaps (B–D), transition states (E–F), and a feedback loop (G–H). Those are the parts that make the method work.

Module 8 covers how this fits with agile delivery.

Reflection

Think of a recent cross-team initiative in your organization. Which ADM phases did it effectively go through, and which did it skip? What did skipping cost?
What would your one-page “how we do architecture” note say?
Which ADM deliverables would your stakeholders actually read?