TOGAF Artifacts and Deliverables: The Complete Checklist

TOGAF Artifacts vs Deliverables: Quick Answer

In TOGAF, a Deliverable is a formal, signed-off work product defined in the Statement of Architecture Work (e.g., the Business Architecture Document). An Artifact is the detailed content within that deliverable — a Catalog, Matrix, or Diagram. Artifacts are the tools; Deliverables are the results that stakeholders review and approve.

One of the most confusing aspects of TOGAF is the distinction between Artifacts and Deliverables. New architects often use these terms interchangeably, but they have very specific meanings in the ADM.

Understanding this difference is critical for both the TOGAF certification exam and for managing your daily work as an enterprise architect. Let's break down exactly what they are and which ones you'll need for each phase of the ADM.

Deliverables vs. Artifacts: What's the Difference?

The easiest way to think about it is this: Deliverables are the final, formal containers that are reviewed and signed off by stakeholders or the Architecture Board. Artifacts are the individual components — the diagrams, tables, and lists — that are used to create those deliverables.

What is a Deliverable?

A Deliverable is a contractual-style document. It represents a completed piece of work that is specified in the Statement of Architecture Work. Example: The Business Architecture Document is a Deliverable.

What is an Artifact?

An Artifact is a discrete piece of architectural information. TOGAF divides artifacts into three categories:

Catalogs: Lists of things (e.g., a list of all applications).
Matrices: Relationships between things (e.g., which applications use which data).
Diagrams: Visual representations of things (e.g., a process flow diagram).

Example: An Application-Communication Diagram is an Artifact that goes inside an Information Systems Architecture Deliverable.

The Master Checklist: Key Deliverables by Phase

Each Phase of the ADM has its own set of mandatory and optional deliverables. Here are some of the most important ones you'll encounter.

1. Preliminary Phase

Architecture Principles: The core rules that govern every architecture decision.
Organizational Model for Enterprise Architecture: Defines the team's structure and governance.

2. Phase A: Architecture Vision

Architecture Vision: The high-level "sales pitch" for the architecture project.
Statement of Architecture Work: The project plan and contract between the architecture team and the business.

3. Phases B, C, and D: Architecture Domains

Architecture Definition Document: The central deliverable containing the baseline and target architectures for each domain.
Architecture Requirements Specification: The formal list of all business and technical requirements the architecture must meet.

4. Phase E and F: Planning and Migration

Architecture Roadmap: The timeline of when each piece of the architecture will be delivered.
Implementation and Migration Plan: The detailed project plan for moving from the current state to the target state.

5. Phase G and H: Governance and Change

Compliance Assessment: Documentation showing how well an implementation project is following the architecture.
Architecture Contract: The agreement between the architect and the implementation team.

How to Choose Which Artifacts to Use

The ADM is a guide, not a rigid rulebook. You do not need to create every artifact TOGAF describes for every project. This is called tailoring.

The key is to ask: "What information do my stakeholders need to make an informed decision?"

If you're talking to a CFO, a Cost-Benefit Matrix might be more valuable than a deep technical diagram.
If you're talking to a Lead Developer, they'll want to see Application-Communication Diagrams and Data Entity Catalogs.

A Practical Artifact Example: The Application Portfolio Catalog

One of the most practically useful artifacts is the Application Catalog — a comprehensive list of every application in the enterprise, including its owner, status, key capabilities, and technology platform.

A well-maintained Application Catalog gives decision-makers instant insight into:

Which applications are approaching end of life and need replacement.
Which applications serve the same function and could be consolidated.
Which applications are running on non-standard technology (SIB violations).
Which business capabilities have no application support (gaps).

This catalog is produced in Phase C and stored in the Architecture Repository's Landscape. It is updated in Phase H as changes occur. The Application Catalog directly informs the TOGAF Architecture Requirements Specification — particularly when identifying application architecture requirements and gaps.

For the visual notation used to draw diagrams within deliverables, see ArchiMate Modeling for TOGAF. For the official list of all TOGAF artifacts and deliverables, refer to the TOGAF 9.2 Content Framework from The Open Group. An additional resource is the TOGAF standard overview which maps every deliverable to its ADM phase.

Common Questions About TOGAF Artifacts and Deliverables

Q: Do I need to produce all TOGAF artifacts on every project?

No. TOGAF explicitly requires tailoring. The ADM is a guide, not a rigid checklist. For a small project affecting a single business unit, producing a Business Process Catalog, a Gap Analysis, and an Architecture Definition Document may be entirely sufficient. For an enterprise-wide transformation, you may need the full set of catalogs, matrices, and diagrams for each domain. The key question is always: what information do the decision-makers need to approve and govern this work?

Q: What is the difference between a Building Block and an Artifact?

A Building Block (either Architecture Building Block or Solution Building Block) is a reusable component of the target architecture — it describes a capability or physical solution. An Artifact is a work product that documents or represents the architecture. An Application Catalog is an artifact. The applications listed in that catalog are Building Blocks. The official definitions are maintained in the TOGAF standard from The Open Group.

Q: Which deliverables require formal sign-off?

The Statement of Architecture Work always requires signatures — this is non-negotiable in TOGAF. Architecture Contracts also require formal sign-off between the architecture team and implementation sponsors. The Architecture Vision is reviewed and endorsed by executive sponsors. Other deliverables — such as individual domain Architecture Definition Documents — may be reviewed and approved by the Architecture Board rather than requiring executive signatures. The full list of deliverables and their governance requirements is specified in the TOGAF Architecture Content Framework.

Summary

Deliverables are the formal results of your work, while artifacts are the tools and views you use to get there. By organizing your work into catalogs, matrices, and diagrams, you can build clear, compelling deliverables that get signed off by senior leadership and successfully guide implementation teams.

In our next post, we will look at one of the most powerful languages for creating these artifacts: ArchiMate Modeling for TOGAF.

This post is part of the TOGAF 9.2 Masterclass series. Don't forget to check out our previous post on The TOGAF Architecture Repository.

Common Mistakes with TOGAF Artifacts and Deliverables

1. Confusing artifacts, deliverables, and building blocks In TOGAF's Content Metamodel: an artifact is a specific architectural work product (a catalog, matrix, or diagram). A deliverable is a formally reviewed and approved document that contains one or more artifacts — it is the contractual output of an ADM phase. A building block is a reusable component (either architectural or solution-level). Mixing these terms in governance conversations creates ambiguity about what is being produced and reviewed.

2. Producing every deliverable in every engagement TOGAF's full deliverable set is comprehensive by design — it covers the most complex enterprise transformation scenarios. For a focused initiative, producing all Phase B deliverables is disproportionate. Apply judgment: produce the artifacts that address actual stakeholder concerns and governance obligations, nothing more. The Preliminary Phase should explicitly tailor the deliverable set for the organisation's context.

3. Not versioning deliverables correctly Architecture deliverables evolve through multiple states: draft, under review, approved, superseded. A governance log that lacks version history makes it impossible to understand the architectural intent at any point in time. Use a document management or version control system that supports versioning and assigns each approved deliverable an immutable version number.

4. Treating catalogs as one-time outputs Catalogs (Application Portfolio Catalog, Technology Portfolio Catalog, Data Entity Catalog) are most valuable when maintained as living inventories. A catalog that is accurate at project completion but never updated becomes misleading within months. Assign stewardship responsibility and tie catalog updates to operational change management processes.

5. Missing the Architecture Requirements Specification The Architecture Requirements Specification is the most frequently overlooked deliverable. It documents the quantitative and testable requirements each architecture domain must satisfy — availability targets, data residency constraints, API response time budgets. Without it, the Target Architecture has no acceptance criteria and cannot be validated against business requirements.

Frequently Asked Questions

What is the difference between a catalog, matrix, and diagram in TOGAF? TOGAF groups artifacts into three categories: Catalogs are lists of things (applications, data entities, technology components, business services) — the raw inventory of the architecture. Matrices show relationships between two catalogs as a grid (e.g., Application/Technology Matrix showing which apps run on which infrastructure). Diagrams provide visual representations of architecture views for stakeholder communication. Each ADM phase produces a defined set of catalogs, matrices, and diagrams documented in the TOGAF Architecture Content Framework.

What is the Statement of Architecture Work? The Statement of Architecture Work is produced at the end of Phase A (Architecture Vision) and formally initiates the architecture engagement. It defines the scope, the approach, the schedule, the resources required, and the acceptance criteria for the architecture work. It is the architecture team's project charter — it requires formal approval from the sponsoring organisation before Phase B work begins.

What is the Architecture Definition Document? The Architecture Definition Document (ADD) is the primary deliverable produced across Phases B, C, and D. It captures the Baseline and Target architectures for each domain (Business, Information Systems, Technology) and evolves throughout the ADM cycle. It typically contains the key diagrams, a description of each architectural component, the rationale for architectural decisions, and the constraints and standards the target architecture must comply with. The ADD is distinct from the Architecture Requirements Specification, which documents testable requirements rather than descriptive content.