TL;DR
In ADM, outputs are mainly artifacts and deliverables. Artifacts describe parts of the architecture (as catalogs, matrices, and diagrams). Deliverables are formal, reviewed outputs that package those artifacts for governance, approval, and implementation.

Why this matters in ADM
A lot of ADM confusion comes from this question: “What do we actually produce in each phase?”
Short answer:
- Artifacts = detailed architecture work products
- Deliverables = formal outputs that contain artifacts and are reviewed/approved
Artifacts: what they are
An artifact is an architectural work product that describes an aspect of the architecture.
In TOGAF-style content, artifacts are commonly grouped as:
- Catalog: list of things
- Matrix: relationships between things
- Diagram: visual representation of things and relationships
Examples:
- Business Capability Catalog (catalog)
- Capability-Organization Matrix (matrix)
- Organization Map (diagram)
Practical pattern many teams use:
- capture detailed facts in catalogs/matrices
- then create diagrams for communication and decision-making
Deliverables: what they are
A deliverable is a formal work product of the architecture engagement.
In practice, deliverables are:
- scoped for stakeholder review and sign-off
- versioned and controlled
- archived in the Architecture Repository
Deliverables are often document “containers” that package multiple artifacts.
Relationship: artifacts inside deliverables
Deliverables and artifacts are not competitors; they work together.
flowchart LR A1["Artifact: Catalog"] A2["Artifact: Matrix"] A3["Artifact: Diagram"] D["Deliverable<br/>(formal package for review/approval)"] R["Architecture Repository<br/>(storage and reuse)"] A1 --> D A2 --> D A3 --> D D --> R
Example:
- Deliverable: Architecture Definition Document
- Included artifacts: Business Capability Map, Process Flow Diagram, Use Case Diagram, data/application/technology artifacts
How outputs evolve across ADM phases
ADM outputs usually start coarse and become more detailed.
A common pattern:
- an early draft starts in Phase A
- architecture definition content is enriched in Phases B, C, and D
- roadmap and migration detail are finalized in Phases E and F
- conformance and change outputs continue in Phases G and H
So, approved does not always mean “final forever”.
It means “approved at this stage”, and further changes must go through governance/change control.
Common deliverable examples by phase
Typical examples used in TOGAF-aligned ADM work:
| Phase | Typical deliverable examples |
|---|---|
| A | Architecture Vision, Statement of Architecture Work, early Architecture Definition Document draft, initial Architecture Requirements Specification |
| B/C/D | Architecture Definition Document, expanded Architecture Requirements Specification |
| E/F | Architecture Roadmap, Implementation and Migration Plan |
| G | Architecture Contract, Compliance Assessments |
| H | Architecture Change Request |
Deliverable status and control
A practical minimum status model is:
- Draft: in progress, not yet formally approved
- Approved: reviewed and accepted by the right governance body
Organizations can extend this with additional statuses, but the key rule is the same:
- after approval, changes must follow change control and governance
Artifacts, deliverables, and building blocks
In TOGAF content thinking:
- Building blocks define reusable architecture/solution components
- Artifacts describe architecture aspects
- Deliverables package artifacts for formal governance and execution
- The Architecture Definition Document packages complementary artifacts that describe the building blocks relevant to an architecture project.
If you want ABB vs SBB details, see:
Exam note
- Artifacts describe architecture; deliverables formalize and package architecture outputs.
- Artifact types are commonly catalogs, matrices, and diagrams.
- Deliverables typically contain multiple artifacts.
- Deliverables are versioned, reviewed, and controlled through governance.
- Outputs evolve across ADM phases; approved outputs can still change via change control.