In Enterprise Architecture (EA), turning strategy into reality requires structured documentation. The Architecture Development Method (ADM) produces a standardized set of work products known as ADM Deliverables. These deliverables act as the contractual, formal, and traceable outputs of an architecture project. They ensure that every stakeholder shares a common understanding, that decisions are documented, and that implementation aligns with the original vision.
This guide provides a complete, beginner-friendly breakdown of every ADM deliverable, its purpose, where it appears in the ADM cycle, and practical examples to make the concepts tangible.
Before diving into the catalog, it’s essential to understand three foundational concepts:
Contractual & Formal: Deliverables are typically contractually specified, formally reviewed, agreed upon, and signed off by stakeholders. They serve as the official record of an architecture project.
Baseline for Tailoring: TOGAF provides a recommended baseline set of deliverables. Organizations are expected to tailor, rename, or omit them to fit their specific processes, culture, or project management methodologies (e.g., PRINCE2, PMBOK, CMMI).
Lifecycle Flow: Deliverables are consumed and produced at different points in the ADM cycle. Early outputs (like the Architecture Vision) evolve and are updated in later phases as details are refined.
These documents set the stage, define boundaries, and secure stakeholder buy-in before detailed architecture work begins.
| Deliverable | Purpose & Key Details | ADM Phase | Beginner Example |
|---|---|---|---|
| Request for Architecture Work | A formal document sent from the sponsoring organization to the architecture team to trigger the start of an ADM cycle. Contains high-level business directives. | Preliminary / Phase A trigger | The CO sends a memo: “Initiate an EA project to migrate our on-premise email system to a secure cloud platform within 18 months.” |
| Statement of Architecture Work | Defines the scope, approach, and resources required to complete the ADM cycle. Often forms the basis of a contractual agreement between architecture providers and consumers. | Phase A | A project charter detailing: timeline, budget, team roles, success criteria, and approval gates for the cloud migration project. |
| Architecture Vision | A high-level, aspirational summary of the changes the enterprise will experience once the Target Architecture is deployed. Aligns stakeholders on the “why” and “what.” | Phase A | A 3-page executive briefing showing how cloud email will reduce costs by 30%, improve mobile access, and meet new security compliance standards. |
| Communications Plan | Outlines how, when, and to whom architecture information will be shared. Critical for managing stakeholder expectations and ensuring targeted information reaches the right people. | Phase A | A schedule showing: weekly status emails for IT staff, monthly steering committee presentations, and quarterly town halls for end-users. |
| Tailored Architecture Framework | Adapts the generic TOGAF framework to fit the organization’s culture, tools, terminology, and specific project needs. Ensures the method is practical and not overly bureaucratic. | Preliminary Phase | A customized EA playbook that replaces TOGAF’s default templates with the company’s existing Confluence wiki structure and Jira workflows. |
These deliverables capture the detailed “blueprint” and the measurable criteria the architecture must satisfy.
| Deliverable | Purpose & Key Details | ADM Phase | Beginner Example |
|---|---|---|---|
| Architecture Definition Document | The primary container for core architectural artifacts across all domains (Business, Data, Application, Technology) and all states (Baseline, Transition, Target). Provides a qualitative view of the solution. | Created in A; updated in B, C, D, E | A comprehensive master document containing process diagrams, data models, system architecture drawings, and security design principles. |
| Architecture Requirements Specification | Provides a set of quantitative, measurable statements that implementation projects must meet to comply with the architecture. Often forms part of vendor contracts. | Phases A–D, finalized in E/F | “The new system must support 10,000 concurrent users, achieve 99.99% uptime, and encrypt all data at rest using AES-256.” |
| Architecture Principles | Enduring, high-level rules and guidelines that inform and govern architecture decisions. Seldom amended. Establish the “guardrails” for design choices. | Preliminary Phase | Principle: “Data is a shared enterprise asset.” Implication: No department may build isolated databases without enterprise data governance approval. |
| Business Principles, Goals, & Drivers | Contextual documents that describe the enterprise’s strategic needs, operating model, and success metrics. Usually pre-existing, but referenced heavily in architecture work. | Phase A / Context | Strategic goals like “Expand into Asian markets by 2026,” “Achieve carbon neutrality by 2030,” and “Reduce IT operational costs by 20%.” |
| Capability Assessment | Evaluates the baseline and target maturity/capability of the enterprise, IT function, and architecture practice. Identifies readiness gaps and cultural barriers. | Phase A; updated in Phase E | A maturity scorecard showing: IT Service Management = Level 2 (Repeatable), Cloud Skills = Level 1 (Initial), Business Readiness for Change = Medium. |
| Requirements Impact Assessment | Analyzes how newly discovered facts, external changes, or implementation challenges affect existing architecture requirements and specifications. | Throughout ADM | When a new data privacy law is announced, this assessment documents which architecture requirements must be updated, and the cost/timeline impact. |
These deliverables translate the architectural blueprint into actionable, scheduled projects.
| Deliverable | Purpose & Key Details | ADM Phase | Beginner Example |
|---|---|---|---|
| Architecture Roadmap | Lists individual work packages on a timeline showing progression from Baseline to Target Architecture. Highlights business value delivered at each stage. | Phases E & F | A Gantt-style timeline showing: Q1: Cloud assessment & pilot → Q2: Data migration → Q3: User training → Q4: Full cutover. |
| Implementation and Migration Plan | A detailed schedule of executable projects grouped into managed portfolios/programs. Defines the approach to change, dependencies, costs, and resource allocation. | Outline in E; Finalized in F | A project portfolio plan linking the cloud migration to 5 subordinate IT projects, detailing budget phases, risk mitigation, and dependency chains. |
| Implementation Governance Model | Defines how the architecture will be governed during implementation. Specifies processes, roles, responsibilities, and compliance checkpoints for transitioning architectures. | Phase F | A RACI matrix and governance workflow defining: who approves design changes, how compliance is audited, and escalation paths for deviations. |
These ensure that implementation stays aligned with the architecture and that changes are managed formally.
| Deliverable | Purpose & Key Details | ADM Phase | Beginner Example |
|---|---|---|---|
| Architecture Contract | A joint agreement between development partners and sponsors on deliverables, quality, and fitness-for-purpose. Ensures continuous monitoring, risk management, and adherence to standards. | Phase G | A signed agreement between the architecture team and a systems integrator specifying: deliverables, SLAs, compliance checkpoints, and change request procedures. |
| Compliance Assessment | Periodic reviews conducted during implementation to verify that projects align with the original Architecture Vision and strategic objectives. Feeds lessons back into the EA process. | Phase G | A quarterly audit report confirming that the deployed cloud infrastructure matches the approved security architecture, with findings and corrective actions. |
| Change Request | Formal documentation submitted when implementation realities, market shifts, or new technologies invalidate the original architecture. Requests dispensation or triggers a new ADM cycle. | Phase H | A request to modify the architecture scope because a critical vendor discontinued a required component, necessitating a re-evaluation of the target design. |
These establish the environment, structure, and storage systems needed to sustain enterprise architecture as an ongoing practice.
| Deliverable | Purpose & Key Details | ADM Phase | Beginner Example |
|---|---|---|---|
| Organizational Model for Enterprise Architecture | Defines the roles, responsibilities, boundaries, and governance relationships required to run an EA practice successfully. Clarifies who does what and how teams interact. | Preliminary Phase | An org chart and operating model defining: Enterprise Architects, Domain Architects, Architecture Board members, and their reporting lines. |
| Architecture Repository | A structured holding area (often tool-supported) for all architecture-related assets. Manages deliverables, catalogs reusable components, and publishes outputs to stakeholders. | Throughout ADM | A centralized EA platform (like ArchiMate tool or SharePoint) containing models, standards, past projects, reference architectures, and compliance logs. |
While detailed in other TOGAF sections, building blocks are critical deliverables that represent architectural and solution capabilities.
| Deliverable | Purpose & Key Details | ADM Phase | Beginner Example |
|---|---|---|---|
| Architecture Building Blocks (ABBs) | Documentation and models from the Architecture Repository that define what functionality is required. Guide the development of solutions. Capture requirements across BDAT domains. | Phases A–D | An ABB named “Customer Identity Management” specifying required features: SSO, MFA, GDPR compliance, and API interfaces. |
| Solution Building Blocks (SBBs) | Implementation-specific components that define how functionality will be realized. Represent actual products, custom developments, or services that implement ABBs. | Phase E onwards | The SBB for the above ABB: “Okta Identity Cloud” configured with specific modules, deployed on AWS, and integrated via REST APIs. |
Qualitative vs. Quantitative:
The Architecture Definition Document tells you what the architecture looks like and why it’s designed that way (qualitative).
The Architecture Requirements Specification tells you exactly what metrics must be met during build and deployment (quantitative). Both are needed for successful implementation.
Deliverables Evolve: Don’t treat early deliverables as final. The Architecture Vision created in Phase A is intentionally high-level. It becomes increasingly detailed as you move through Phases B, C, and D, eventually populating the Architecture Definition Document.
Tailoring is Expected: TOGAF provides a comprehensive baseline, but you should never force every deliverable into every project. Scale deliverables to match project size, risk, and organizational maturity. A small project might combine the Vision and Statement of Work; a large program might split them into 10+ documents.
Governance Relies on Contracts & Assessments: The Architecture Contract and Compliance Assessment are the “enforcement” mechanisms. Without them, architecture becomes theoretical. They ensure what was designed is actually built.
Repository as a Living Asset: The Architecture Repository isn’t just a filing cabinet. It’s a strategic asset that grows with each ADM cycle. Reusable ABBs, past Compliance Assessments, and Reference Models stored here dramatically speed up future architecture work.
ADM Deliverables are the connective tissue between enterprise strategy and IT execution. They provide structure, ensure accountability, enable stakeholder alignment, and create a reusable knowledge base for future initiatives. By understanding the purpose, timing, and practical application of each deliverable, beginners can navigate the TOGAF ADM with confidence, ensuring that architecture projects deliver tangible, measurable business value rather than remaining abstract diagrams.
