TOGAF ADM Phases and Sparx EA: What to Build in Each Phase

The TOGAF Architecture Development Method has nine lettered phases (A through H), plus a Preliminary phase and a continuous Requirements Management thread. Each produces specific artifacts. In Sparx EA, those artifacts live as models, diagrams, matrices, and tagged-value-governed elements inside a structured package hierarchy. This is a map of each phase: what you build, where it belongs, and what Sparx EA gives you to build it with.

The TOGAF ADM at a glance

Phase	Name	Primary deliverables
Preliminary	Foundation Setup	Architecture principles, governance model, tailored ADM, EA tool configuration
A	Architecture Vision	Statement of Architecture Work, Architecture Vision, stakeholder map, high-level capability assessment
B	Business Architecture	Business Architecture document, business capability map, process models, role/actor mapping
C	Information Systems Architecture	Data and Application Architecture documents, data entity diagrams, application portfolio, app-capability mapping
D	Technology Architecture	Technology Architecture document, infrastructure models, technology standards
E	Opportunities & Solutions	Initial Architecture Roadmap, Transition Architectures, Implementation Factor Assessment
F	Migration Planning	Detailed Architecture Roadmap, Migration Plan, Implementation and Migration Plan
G	Implementation Governance	Architecture Contracts, compliance reviews, post-implementation review
H	Architecture Change Management	Change requests, impact assessments, updated baseline architecture
RM	Requirements Management	Requirements repository, traceability, change log (continuous across all phases)

Preliminary: foundation

The Preliminary phase is often treated as administrative. It isn’t — it’s where the practice is set up to be effective. In Sparx EA, this phase produces the repository structure itself: the top-level package hierarchy, MDG Technology configuration, naming conventions, access-control groups, and the governance model that applies to everything downstream. Skip or rush it, and every later phase pays the price in rework.

Phase A: Architecture Vision

Phase A establishes scope and intent. The primary deliverable is the Architecture Vision — a high-level view of what will be achieved, for whom, and how success is measured. In Sparx EA it’s typically a structured package containing stakeholder models (ArchiMate Stakeholder elements), driver and goal models (Motivation layer), a high-level capability map, and the Statement of Architecture Work as a document linked to the model. Sparx EA’s document generation can produce that statement directly from model content. The stakeholder register built here becomes the foundation for all later stakeholder communication.

Phase B: Business Architecture

Phase B produces the Business Architecture — the most important phase for business-facing work. Deliverables include a capability map, process models, organizational models, and role/actor mapping. In Sparx EA this lives in the Business Architecture package using ArchiMate Business layer elements: the Business Capability Map (Capability elements connected to Functions and Services), Business Process models (ArchiMate or BPMN, depending on the detail required), and Actor/Role models. The capability map produced here tends to be the most-referenced artifact in the whole repository.

Phase C: Information Systems Architecture

Phase C has two parts — Data and Application Architecture — often compressed into one phase in practice but addressing distinct concerns.

Data Architecture describes the enterprise’s information assets: what data exists, how it’s structured, who owns it, how it flows. In Sparx EA: data entities as ArchiMate Data Objects or UML classes, data flow diagrams, classification tags, and ownership registers as tagged values on Data Object elements.

Application Architecture describes the portfolio and how applications support capabilities. In Sparx EA: Application Components (ArchiMate), Application Services, application-to-capability mapping matrices (Sparx EA’s matrix tool), and lifecycle tagged values on each component — status, retirement date, health score, owner. This package is the foundation for any application portfolio management work that follows.

Phase D: Technology Architecture

Phase D describes the infrastructure that hosts and runs the portfolio. Deliverables: a Technology Architecture document, infrastructure models, and a technology standards catalog. In Sparx EA: Technology layer elements (Node, Device, System Software, Communication Network), deployment diagrams showing applications hosted on infrastructure, and standards as a reference package with tagged values for standard status (approved, emerging, deprecated). This is also where security and cloud architecture models commonly live — either as extended Technology layer elements or as supplementary notations linked to ArchiMate.

Phases E and F: roadmap and migration planning

Phase E identifies gaps between baseline and target and produces the initial Architecture Roadmap; Phase F develops it into a detailed Migration Plan with sequenced work packages. In Sparx EA: gap-analysis matrices comparing baseline and target elements, Work Package elements (Implementation & Migration layer), Transition Architecture packages for intermediate states, and the roadmap as a time-sequenced diagram of Work Packages and Plateaus.

Phases G and H: governance and change

Phase G governs implementation — ensuring what gets built conforms to the approved architecture. Phase H manages ongoing change. In Sparx EA: Architecture Contracts as structured documents linked to model packages, compliance review checklists, and change requests linked to affected elements. Sparx EA’s baseline capability lets you freeze approved states for compliance comparison.

Requirements Management: the cross-phase thread

Requirements Management isn’t a single phase — it runs continuously across all of them. Every phase produces, consumes, or modifies requirements. In Sparx EA, requirements are modeled as structured elements with tagged values (priority, source, status, trace), organized in a Requirements package with trace relationships to architecture elements across all layers. The matrix tool supports traceability views showing which requirements are addressed by which elements — a fundamental governance output.

Why phase structure pays off

A TOGAF-structured Sparx EA repository — phase-organized packages, typed elements, consistent relationships — is far more useful than an unstructured one. Questions like “what are the target capabilities from Phase B?” or “which applications map to the Finance capability?” are answerable when the repository carries real model structure. They are not answerable from a collection of diagrams with nothing underneath. That structure is what makes the repository a model you can interrogate — whether the question comes from an architect, a matrix report, or a downstream analytics tool. Phase governance isn’t just good practice; it’s the difference between a repository you can query and one you can only browse.

Frequently asked questions

If your TOGAF practice currently lives in documents rather than models, the move into a structured Sparx EA repository is where the payoff starts. Our Paralysis to a Plan engagement assesses your current structure and ADM alignment and produces a concrete roadmap for closing the gaps — the right starting point for architecture leaders who want models, not just deliverables.