Structured along the TOGAF Architecture Development Method (ADM)
Why Architecture Needs a Method
Good architecture is not produced by accident. It emerges from a structured process that ensures business goals are understood before systems are designed, and systems are designed before technology is selected. The TOGAF Architecture Development Method (ADM) provides exactly this — a repeatable, phase-by-phase approach to creating, governing, and evolving enterprise-grade architectures.
This article describes how architecture services are delivered along each phase of the ADM lifecycle — from the initial Architecture Vision through to ongoing Change Management. Each phase produces concrete, tangible deliverables that serve both leadership teams and implementation teams.
| What is TOGAF ADM? TOGAF (The Open Group Architecture Framework) is the most widely adopted enterprise architecture framework. Its core is the Architecture Development Method (ADM) — a cycle of phases that guides architects from strategy and vision through to implemented, governed, and continuously improved systems. It is framework-agnostic: it works with any technology stack, any industry, and any organization size. |
The ADM Lifecycle at a Glance
The ADM is structured as a cycle, not a waterfall. It begins with foundational groundwork, moves through four architecture domains, then into planning and governance, and loops back through change management. At its center sits continuous Requirements Management, which informs every phase.
Diagram: ADM Cycle Overview
Preliminary Phase — Setting the Foundation
Before any architecture work begins, it is essential to define how architecture will be done. The Preliminary Phase establishes the architectural framework, governance model, and principles that will guide every subsequent decision. It answers the question: what are the rules of engagement?
WHAT HAPPENS IN THIS PHASE
- Define or adopt an architecture framework (e.g. TOGAF, adapted to the organization)
- Establish architecture governance structures and roles
- Agree on architecture principles — the standing rules that guide all decisions
- Identify existing architecture repositories and reference models
- Define tools, templates, and standards to be used across the engagement
KEY DELIVERABLES
| Deliverable | Description | Format |
| Architecture Principles | A documented set of standing rules that guide architecture decisions (e.g. ‚API-first‘, ’single source of truth‘, ‚loose coupling‘) | Document / Table |
| Governance Model | Who makes architecture decisions, how they are reviewed, and how compliance is ensured | Document |
| Tailored Framework | A description of how TOGAF is adapted and applied in this specific context | Document |
A. Architecture Vision — Alignment Before Design
The Architecture Vision phase establishes a shared, high-level picture of where the initiative is going and why. It is the critical alignment point between business stakeholders and the architecture team. No system should be designed before this shared understanding exists.
THIS PHASE ANSWERS
- What problem are we solving?
- Who is affected?
- What does success look like?
- What is in scope — and what is explicitly not?
WHAT HAPPENS IN THIS PHASE
- Identify and engage key stakeholders and their concerns
- Define the scope of the architecture engagement
- Create a high-level vision of the target architecture
- Identify constraints: regulatory, organizational, technical, financial
- Produce a Statement of Architecture Work to formally kick off the engagement
KEY DELIVERABLES
| Deliverable | Description | Format |
| Stakeholder Map | A register of all stakeholders, their roles, primary concerns, and level of influence | Table |
| System Context Diagram | A high-level diagram showing the system in the center, with all external actors, users, and neighboring systems around it | Diagram |
| Architecture Vision Document | A concise document summarizing the target state, scope, key drivers, and constraints | Document |
| Statement of Architecture Work | A formal agreement defining what will be delivered, by when, and how success will be measured | Document |
EXAMPLE — STAKEHOLDER MAP
| Stakeholder | Role | Primary Concern | Influence |
| IT Leadership | Architecture Sponsor | Consistency & strategic fit | High |
| Business Owner | Key Stakeholder | Process support & outcomes | High |
| Development Teams | Implementers | Technical feasibility & clarity | Medium |
| Operations | Operators | Availability & maintainability | Medium |
| [Add stakeholder] | [Role] | [Primary concern] | [Influence] |
Diagram: System Context Diagram
B. Business Architecture — Understanding How the Business Works
Before designing any system, the business must be understood on its own terms. The Business Architecture phase maps the processes, capabilities, roles, and rules that the IT landscape must support. This creates the bridge between business intent and IT design.
A common failure in IT projects is jumping straight to system design without this step — resulting in systems that technically work but do not align with how the business actually operates. Business Architecture prevents this.
WHAT HAPPENS IN THIS PHASE
- Map the relevant business processes from end to end
- Identify business capabilities: what the organization needs to be able to do
- Define organizational roles and responsibilities relevant to the system
- Identify business rules, constraints, and compliance requirements
- Highlight gaps between current capabilities and the target state
KEY DELIVERABLES
| Deliverable | Description | Format |
| Business Process Flows | An end-to-end process diagrams showing roles, activities, decision points, and handovers between systems or teams | Diagram (BPMN) |
| Business Capability Map | A structured view of what the organization needs to be able to do, assessed for current strength and strategic importance | Diagram / Table |
| Role & Responsibility Matrix | Who does what, at which stage of the process, in which system | Table (RACI) |
| Business Rules Register | Key rules, policies, and constraints that the system must enforce or respect | Table / Document |
Diagram: End-to-End Business Process Flow
Diagram: Business Capability Map
C. Information Systems Architecture — Data & Applications
Phase C “Information Systems Architecture” addresses the Information Systems layer in two complementary views: Data Architecture and Application Architecture. Together, they answer: what data exists, where does it live, who owns it — and which applications manage, transform, and expose that data?
This phase is where many of the hardest integration challenges become visible. By making data ownership and application responsibilities explicit, it becomes possible to design clean, maintainable interfaces rather than fragile point-to-point connections.
C1. Data Architecture
Data Architecture defines the logical structure of the organization’s data: what entities exist, how they relate to each other, which system is the authoritative source for each entity, and how data flows across system boundaries.
KEY DELIVERABLES — DATA ARCHITECTURE
| Deliverable | Description | Format |
| Logical Data Model | An entity-relationship diagram showing key business objects, their attributes, and relationships — independent of any specific database implementation | Diagram (ERD) |
| Data Ownership Register | A table mapping each key data entity to its system of record — the single authoritative source | Table |
| End-to-End Data Flow Diagram | A diagram showing how data moves across systems: source, transformation steps, and destinations, with data types and latency expectations | Diagram (DFD) |
Diagram: Logical Data Model
Diagram: End-to-End Data Flow
C2. Application Architecture
Application Architecture defines the logical applications, their responsibilities, and how they interact. It answers: which application does what, and how do they communicate?
KEY DELIVERABLES — APPLICATION ARCHITECTURE
| Deliverable | Description | Format |
| Application Landscape Diagram | A diagram of all relevant applications, grouped by domain or function, showing integration points between them | Diagram |
| Application Interaction Matrix | A table showing which application calls or depends on which, with the integration pattern used (API, event, file, etc.) | Table |
| API Catalog | A register of all interfaces: endpoint, method, payload structure, error handling, and versioning approach | Table / Spec |
| Sequence Diagrams | Step-by-step interaction diagrams for the most critical runtime scenarios — showing which system calls which, in what order | Diagram (UML) |
EXAMPLE — API CATALOG (EXCERPT)
| Endpoint / Resource | Method | Purpose | Response |
| /resources/{id} | GET | Retrieve a single resource by identifier | 200 / 404 |
| /resources | POST | Create a new resource | 201 / 422 |
| /resources/{id} | PUT | Update an existing resource | 200 / 404 |
| /events/{type} | GET | Subscribe to domain events | 200 stream |
| [Add endpoint] | [Method] | [Purpose] | [Response] |
Diagram: Application Landscape
Diagram: Sequence Diagram
D. Technology Architecture — Infrastructure & Deployment
Phase D “Technology Architecture” translates the logical application and data architecture into a concrete infrastructure view: which technologies, platforms, runtimes, and deployment models are required to bring the system to life and keep it running reliably.
This phase bridges architecture and engineering. Its outputs are the foundation for deployment planning, infrastructure provisioning, and operational runbooks.
WHAT HAPPENS IN THIS PHASE
- Define the technology stack: languages, frameworks, platforms, and services
- Design the deployment architecture: cloud, on-premises, or hybrid
- Address non-functional requirements: availability, scalability, security, and performance
- Define environments: development, testing, staging, and production
- Identify infrastructure dependencies and provider constraints
KEY DELIVERABLES
| Deliverable | Description | Format |
| Deployment Diagram | Shows where each component runs: servers, containers, cloud services, on-premises infrastructure, and network boundaries | Diagram |
| Technology Stack Overview | A structured summary of the chosen technologies per layer: frontend, backend, integration, data storage, and infrastructure | Table / Document |
| Environment Map | A diagram or table describing each environment (dev, test, staging, prod), what runs in it, and how they relate | Diagram / Table |
| Non-Functional Requirements | A structured specification of availability targets, performance SLAs, security requirements, and disaster recovery objectives | Table / Document |
Diagram: Deployment Architecture
E. Opportunities & Solutions — Defining the Path Forward
Having defined the target architecture across all four domains, Phase E “Opportunities & Solutions” identifies the gap between where the organization is today and where it needs to be — and defines the work packages needed to close that gap. It is the bridge between architecture and execution.
WHAT HAPPENS IN THIS PHASE
- Perform a gap analysis: current state versus target state, per architecture domain
- Identify and group the changes needed into logical work packages
- Evaluate build vs. buy vs. reuse decisions for each component
- Identify quick wins and foundational enablers that unblock later work
- Define the overall transition approach and key dependencies
KEY DELIVERABLES
| Deliverable | Description | Format |
| Gap Analysis | A structured comparison of the current and target architecture, highlighting what needs to be built, changed, integrated, retired, or left as-is | Table / Diagram |
| Work Package Register | A list of discrete architecture work packages, each with a scope, rationale, and estimated effort | Table |
| Build / Buy / Reuse Matrix | An assessment of each component: whether to build custom, purchase a product, or reuse an existing asset | Table |
| Dependency Map | A diagram showing which work packages depend on others — used to sequence delivery and identify critical path items | Diagram |
F. Migration Planning — From Architecture to Roadmap
Phase F “Migration Planning” turns the work packages from Phase E “Opportunities & Solutions” into a sequenced, prioritized migration roadmap. It produces the plan that delivery teams and leadership can commit to — showing what will be done, in what order, and when.
WHAT HAPPENS IN THIS PHASE
- Prioritize work packages based on business value, risk, and dependencies
- Define transition architectures — the intermediate states the system passes through on the way to the target
- Sequence initiatives into delivery increments or release phases
- Identify risks associated with the migration and define mitigations
- Align the roadmap with the organization’s budget and delivery capacity
KEY DELIVERABLES
| Deliverable | Description | Format |
| Architecture Roadmap | A sequenced plan of initiatives, showing what changes in which order and in what timeframe | Diagram / Table |
| Transition Architecture(s) | Descriptions of the intermediate states between current and target — ensuring the system remains operational throughout the transition | Document / Diagram |
| Migration Risk Register | A register of risks associated with the migration, with likelihood, impact, and mitigation actions | Table |
EXAMPLE — MIGRATION ROADMAP (EXCERPT)
| Initiative | Dependencies | Effort | Priority | Timeline |
| [Quick win / foundation] | None | Low | 1 — Now | Q1 |
| [Core integration work] | [Initiative A] | High | 2 — Next | Q2-Q3 |
| [Legacy decommission] | [Initiative B] | Medium | 3 — Later | Q4+ |
| [Add initiative] | [Dependencies] | [Effort] | [Priority] | [Timeline] |
G. Implementation Governance — Architecture in Delivery
Architecture value is only realized when the implemented system reflects the designed architecture. Phase G “Implementation Governance” ensures this by establishing governance over the implementation process — reviewing delivered components, tracking conformance, and managing deviations.
This phase does not replace project management or development oversight — it complements them by providing an architecture perspective on what is being built and ensuring decisions remain aligned with the agreed architecture.
WHAT HAPPENS IN THIS PHASE
- Define architecture compliance review checkpoints within the delivery process
- Conduct architecture reviews of implemented components as they are delivered
- Track and document any deviations from the agreed architecture
- Assess the impact of implementation-level decisions on the overall architecture
- Formally close the architecture engagement once delivery is complete and verified
KEY DELIVERABLES
| Deliverable | Description | Format |
| Architecture Compliance Checklist | A checklist used during delivery reviews to verify that each component conforms to the agreed architecture, data model, and API specifications | Checklist / Table |
| Deviation Register | A record of any agreed deviations from the target architecture, with rationale, impact assessment, and approval status | Table |
| Architecture Completion Report | A final report confirming which architecture decisions were implemented, which were deferred, and what remains as technical debt | Document |
H. Architecture Change Management — Keeping Architecture Alive
Architectures are not static. Business needs change, technologies evolve, and new requirements emerge. Phase H “Architecture Change Management” ensures that the architecture remains a living, relevant asset — continuously monitored, and updated in a controlled manner when change is needed.
WHAT HAPPENS IN THIS PHASE
- Monitor the deployed architecture for performance, compliance, and fitness
- Evaluate change requests against the current architecture
- Determine whether a change requires a new ADM cycle or can be handled as a minor update
- Maintain the architecture repository and keep documentation current
- Communicate architecture changes to affected teams
KEY DELIVERABLES
| Deliverable | Description | Format |
| Change Request Assessment | An evaluation of each proposed change: what it affects in the architecture, what the impact is, and whether it triggers a new architecture cycle | Document / Table |
| Updated Architecture Documentation | Revised versions of any architecture artifacts impacted by the change — kept as the living source of truth | Living Document |
| Architecture Review Calendar | A schedule of periodic architecture health reviews to proactively identify drift, debt, or obsolescence | Calendar / Plan |
Requirements Management — The Continuous Thread
Requirements Management is not a phase — it is a continuous activity that runs through every phase of the ADM. It ensures that architecture decisions remain traceable to business requirements, and that changes to requirements are reflected in the architecture in a controlled way.
WHAT HAPPENS CONTINUOUSLY
- Capture and document architecture requirements from stakeholders
- Maintain a requirements repository accessible to all teams
- Trace requirements to architecture decisions and deliverables
- Assess the impact of new or changed requirements on the current architecture
- Prioritize requirements in collaboration with business stakeholders
KEY DELIVERABLES
| Deliverable | Description | Format |
| Architecture Requirements Register | A living register of all architecture-relevant requirements, linked to their source stakeholder and the ADM phase where they are addressed | Table / Tool |
| Traceability Matrix | A matrix linking business requirements to architecture decisions, deliverables, and implemented components | Table |
Architecture Decision Records (ADRs)
Every significant architecture decision produces an Architecture Decision Record (ADR). ADRs are the institutional memory of an architecture engagement — they explain not just what was decided, but why, what alternatives were considered, and what consequences follow from the decision.
ADRs are written when a decision is made and updated when it is revisited or superseded. They are the primary tool for on-boarding new team members, supporting audits, and enabling informed future change.
ADR TEMPLATE
| Field | Content |
| ADR ID | ADR-001 |
| Title | [Short title of the decision] |
| Status | Proposed / Accepted / Deprecated |
| Context | [What situation or problem triggered this decision? What constraints apply?] |
| Decision | [What was decided, and why? What options were considered?] |
| Consequences | [What are the positive and negative consequences of this decision?] |
| When to write an ADR Write an ADR whenever a decision: (1) affects multiple teams or systems, (2) involves a trade-off between competing concerns, (3) is difficult or costly to reverse, or (4) might be questioned or misunderstood later. If in doubt — write it. A one-page ADR written today is worth more than an hour of archaeology six months from now. |
What You Get From Each Engagement
Every architecture engagement is scoped and tailored to the situation. The deliverables below are drawn from the ADM phases described above and combined into a coherent, practically useful output set. Not every engagement requires all phases — but every engagement produces artifacts that are immediately useful to the teams who need them.
ARTIFACT TYPES DELIVERED
| Deliverable | Description | Format |
| Architecture Diagrams | System context, application landscape, deployment, data flow, and sequence diagrams — drawn to communicate clearly to both technical and business audiences | Diagram |
| Data Models & API Specifications | Logical data models, entity maps, and full API catalogs that serve as the single source of truth for integration and development teams | Document / Table |
| Architecture Decision Records | Written records of key decisions — what was decided, why, what was rejected, and what consequences follow | Document |
| Roadmaps & Migration Plans | Sequenced, dependency-aware plans for transitioning from current to target state without disrupting operations | Table / Diagram |
| Governance Artifacts | Compliance checklists, deviation registers, and completion reports that support delivery teams and leadership oversight | Document / Table |