TOGAF Artifacts and Deliverables: The Complete Architect’s Checklist
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.
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.