TOGAF ADM Phases and Sparx EA: What to Build in Each Phase
The TOGAF Architecture Development Method (ADM) has 9 phases (A through H) plus a continuous Requirements Management phase. Each phase produces specific architecture artifacts. In Sparx EA, those artifacts live as models, diagrams, matrices, and tagged-value-governed elements in a structured package hierarchy. Phase A produces the Architecture Vision and stakeholder map. Phases B, C, and D produce the four architecture domain models — Business, Data, Application, Technology. Phase E and F produce the roadmap and migration plan. Phases G and H govern implementation and change. This article maps each phase to what you build in Sparx EA, where it lives in the repository, and what Sparx EA features support it.
Key Takeaways
- The TOGAF ADM has 9 lettered phases plus Requirements Management — each produces distinct deliverables
- Sparx EA supports TOGAF artifact development across all phases through models, matrices, reports, and MDG-governed packages
- Phase B (Business), C (Information Systems), and D (Technology) are the architecture-building phases where most repository content is created
- Requirements Management is a cross-phase concern — not a single phase — and Sparx EA’s Requirements capability handles this throughout
- TOGAF-governed repositories with structured phase artifacts are better prepared for AI integration via EA GraphLink
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 Architecture + Application Architecture documents, data entity diagrams, application portfolio, app-capability mapping |
| D | Technology Architecture | Technology Architecture document, infrastructure models, technology standards |
| E | Opportunities & Solutions | Architecture Roadmap (initial), Transition Architectures, Implementation Factor Assessment |
| F | Migration Planning | Architecture Roadmap (detailed), 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 Phase: Foundation
The Preliminary phase is often treated as administrative — it is not. This is where the EA practice is set up to be effective. In Sparx EA, the Preliminary phase produces the repository structure itself: the top-level package hierarchy, MDG Technology configuration, naming conventions, access control groups, and the governance model that will apply to all subsequent work.
Artifacts in Sparx EA: root package structure, MDG profile configuration, architecture principles (modeled as ArchiMate Principles or stored as structured elements), reference library setup. If this phase is skipped or rushed, every subsequent phase pays the price in rework and inconsistency.
Phase A: Architecture Vision
Phase A establishes the scope and intent for the architecture engagement. The primary deliverable is the Architecture Vision — a high-level view of what will be achieved, for whom, and how success will be measured.
In Sparx EA: Architecture Vision is typically documented as a structured model package containing stakeholder models (ArchiMate Stakeholder elements), driver and goal models (ArchiMate Motivation layer), a high-level capability map, and the Statement of Architecture Work as a formal document linked to the model. Sparx EA’s document generation capability can produce the Statement of Architecture Work directly from model content.
The stakeholder register built in Phase A becomes the foundation for all subsequent stakeholder communication — and, eventually, for Kernaro AI Hub’s audience-aware intelligence delivery.
Phase B: Business Architecture
Phase B produces the Business Architecture — the most important phase for business-facing architecture work. Deliverables include a capability map, process models, organizational models, and the mapping of business roles and actors to processes and services.
In Sparx EA: Business Architecture content lives in the Business Architecture package, using ArchiMate Business layer elements. Key models include the Business Capability Map (ArchiMate Capability elements connected to Business Functions and Services), Business Process models (either ArchiMate or BPMN depending on the level of process detail required), and Actor/Role models showing organizational accountability.
The capability map produced in Phase B is the most queried artifact in AI-augmented architecture — “what capabilities does the organization have?” is one of the first questions Kernaro AI Hub answers.
Phase C: Information Systems Architecture
Phase C has two parts: Data Architecture and Application Architecture. Both are frequently compressed into a single phase in practice, but they address distinct concerns.
Data Architecture describes the information assets of the enterprise — what data exists, how it is structured, who owns it, and how it flows. In Sparx EA: Data entities as ArchiMate Data Objects or UML class models, data flow diagrams, information classification tags, and data ownership registers as tagged values on Data Object elements.
Application Architecture describes the application portfolio and how applications support business capabilities. In Sparx EA: Application Components (ArchiMate), Application Services, Application-to-Capability mapping matrices (using Sparx EA’s matrix tool), and lifecycle tagged values on each Application Component (status, retirement date, health score, owner).
The Application Architecture package from Phase C is what feeds application portfolio management dashboards via EA GraphLink.
Phase D: Technology Architecture
Phase D describes the infrastructure that hosts and runs the application portfolio. Deliverables include a Technology Architecture document, infrastructure models, and a technology standards catalog.
In Sparx EA: Technology layer elements (ArchiMate Node, Device, System Software, Communication Network), deployment diagrams showing applications hosted on infrastructure, and technology standards as a reference package with ArchiMate Technology Service elements and tagged values indicating standard status (approved, emerging, deprecated).
Technology Architecture content is where security architecture and cloud architecture models are also commonly housed — either using ArchiMate Technology layer elements extended for security concerns, or using supplementary notations (AWS, Azure architecture icons) linked to ArchiMate models.
Phases E and F: Roadmap and Migration Planning
Phase E identifies the gaps between Baseline and Target architecture and produces the initial Architecture Roadmap. Phase F develops that roadmap into a detailed Migration Plan with sequenced work packages.
In Sparx EA: Gap analysis matrices (using the matrix tool to compare baseline and target capability/application/technology elements), Work Package elements (ArchiMate Implementation & Migration layer), Transition Architecture packages showing intermediate states, and the Architecture Roadmap as a time-sequenced diagram of Work Packages and Plateaus.
Phases G and H: Governance and Change
Phase G governs implementation — ensuring that what gets built conforms to the approved architecture. Phase H manages ongoing architecture change.
In Sparx EA: Architecture Contracts as structured documents linked to the relevant model packages, compliance review checklists, and change request records linked to affected architecture elements. Sparx EA’s baseline capability allows freezing approved architecture states for compliance comparison.
Requirements Management: The Cross-Phase Thread
Requirements Management is not a single phase — it runs continuously across all ADM phases. 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 architecture elements — a fundamental governance output.
TOGAF-Governed Repositories and AI Integration
A TOGAF-structured Sparx EA repository — with phase-organized packages, typed elements, and consistent relationships — is significantly more useful for AI integration than an unstructured one. When EA GraphLink transforms repository content into AI-accessible data, the structure of TOGAF phase packages becomes queryable context.
Questions like “what are the target capabilities from Phase B?” or “which applications in the portfolio are mapped to the Finance capability?” are answerable when the repository is TOGAF-structured. They are not answerable when the repository is a collection of diagrams with no underlying model structure.
TOGAF governance is not just good architecture practice — it is the foundation for the AI-augmented architecture practice that Kernaro AI Hub and EA GraphLink enable.
FAQ
What are the TOGAF ADM phases in order? Preliminary, then Phases A through H: A (Architecture Vision), B (Business Architecture), C (Information Systems Architecture), D (Technology Architecture), E (Opportunities & Solutions), F (Migration Planning), G (Implementation Governance), H (Architecture Change Management). Requirements Management runs continuously across all phases. The ADM is iterative — teams cycle through phases as programs progress.
What is the difference between Phase B, C, and D in TOGAF? Phase B produces the Business Architecture — what the organization does and how. Phase C produces the Information Systems Architecture — what data exists and what applications support the business. Phase D produces the Technology Architecture — what infrastructure hosts and runs the applications. Together, Phases B, C, and D address the four architecture domains: Business, Data, Application, and Technology.
What does Requirements Management mean in TOGAF? Requirements Management is not a single phase but a continuous process that runs across all ADM phases. It tracks architecture requirements — what the architecture must achieve — and ensures they are addressed, traced to architecture decisions, and updated when circumstances change. In Sparx EA, requirements are modeled as structured elements with traceability to architecture content.
How do I store TOGAF deliverables in Sparx EA? TOGAF deliverables map to packages and models in Sparx EA. The typical structure is a top-level TOGAF package with sub-packages for each phase. Within each phase package: architecture documents linked to the model, typed elements (using ArchiMate MDG for architecture content), matrices, and reports. Document generation in Sparx EA can produce formal deliverables from model content.
What is the Architecture Vision in TOGAF Phase A? The Architecture Vision is the primary deliverable of Phase A. It describes the scope of the architecture engagement, the stakeholders and their concerns, the high-level target state, and the approach to achieving it. It is the document that gets executive sign-off before detailed architecture work begins. In Sparx EA, it is typically produced as a combination of model content (stakeholder map, capability overview) and a generated document.
How does TOGAF governance connect to Kernaro AI Hub? Kernaro AI Hub is Sparx Services’ stakeholder-facing AI product (GA 2026) that gives stakeholders natural language access to architecture intelligence. TOGAF-governed repositories provide the structured content that Kernaro AI Hub queries. When Phase A stakeholder registers, Phase B capability maps, and Phase C application portfolios are well-modeled in Sparx EA, Kernaro AI Hub can answer stakeholder questions like “what capabilities do we have for customer onboarding?” with architecture-grounded answers.
Start With a Structured Foundation
The Sparx Services Discover engagement assesses your current repository structure, ADM alignment, and readiness for AI integration — and produces a concrete roadmap for closing the gaps. If your TOGAF practice lives in documents rather than models, Discover is the right starting point.
