13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs)
Key Takeaways
The TOGAF Content Framework establishes a clear structural hierarchy distinguishing between Deliverables, Artifacts, and Building Blocks.
Deliverables are formal, contractual, signed-off outputs produced by ADM phases that represent verified milestones governed by the Architecture Board.
Artifacts are architectural work products that document specific aspects of an architecture, categorized into three distinct types: Catalogs (inventories), Matrices (relationship mappings), and Diagrams (graphical views).
Building Blocks are reusable components of capability; Architecture Building Blocks (ABBs) define technology-agnostic requirements and functionality, whereas Solution Building Blocks (SBBs) define real-world physical implementations.
The transition from ABBs to SBBs occurs across ADM phases, moving from requirements capture in Phases A-D to candidate solutions in Phase E, procurement in Phase F, and operational deployment in Phase G.
13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs)
A foundational concept tested on the OGEA-103 examination is the structural taxonomy that the TOGAF standard uses to classify architectural work. When an enterprise architecture team executes the Architecture Development Method (ADM), they produce a wide variety of outputs ranging from executive contracts and technical inventories to interactive system diagrams and software component specifications.
To prevent conceptual confusion, the TOGAF Architecture Content Framework establishes a strict three-tier hierarchy of architectural output:
- Deliverables: The formal, contractually specified packages signed off by stakeholders.
- Artifacts: The granular architectural work products (catalogs, matrices, and diagrams) contained inside deliverables.
- Building Blocks: The reusable capability components (ABBs and SBBs) represented within artifacts.
Deliverables: Contractual and Governed Milestones
In the TOGAF Standard, a Deliverable is formally defined as an architectural work product that is contractually specified, formally reviewed, agreed upon, and signed off by stakeholders. Deliverables represent the official outputs of ADM phases and serve as the formal decision gates across the architecture lifecycle.
Deliverables are characterized by three essential traits:
- Contractual Status: They establish formal agreements between architecture teams, executive sponsors, and implementation organizations.
- Governed Lifecycle: A deliverable cannot simply be saved to a shared folder; it must be formally submitted, evaluated against compliance criteria, and signed off by the Architecture Board or designated authority.
- Packaging Mechanism: Deliverables act as containers. They bundle together executive summaries, business rationale, governance parameters, and numerous granular architectural artifacts.
Core TOGAF ADM Deliverables Across the Lifecycle
| ADM Phase | Core Deliverable | Strategic Purpose & Contents |
|---|---|---|
| Preliminary | Architecture Framework & Principles | Establishes the tailored ADM, governance charters, metamodel, and enterprise architecture principles. |
| Phase A | Statement of Architecture Work (SoAW) | The foundational contract between the architecture team and executive sponsor, defining project scope, budget, milestones, and deliverables. |
| Phase A | Architecture Vision | Executive summary of target capabilities, stakeholder value proposition, and high-level operating model. |
| Phases B, C, D | Architecture Definition Document (ADD) | The comprehensive, detailed technical specification of the architecture across Business, Data, Application, and Technology domains, capturing baseline, target, and gap analyses. |
| Phases B, C, D | Architecture Requirements Specification | Captures quantifiable, non-functional requirements, service levels, regulatory constraints, and acceptance criteria. |
| Phase E | Architecture Roadmap | Chronological plan of work packages, milestones, transition architectures, and incremental delivery increments. |
| Phase F | Implementation & Migration Plan | Joint deliverable co-owned with the PMO, detailing project schedules, resource allocations, dependency networks, and business value realization paths. |
| Phase G | Architecture Contract | Legally binding or formal operational agreement between the architecture authority and the implementation delivery organization. |
| Phase G | Compliance Assessment | Formal assessment of whether an implementation conforms to the approved architecture and standards. |
| Phase H | Change Request | Formal request for a change to the architecture; major changes lead to a new Request for Architecture Work. |
Artifacts Taxonomy: Catalogs, Matrices, and Diagrams
An Artifact is an architectural work product that describes an aspect of the architecture. Unlike deliverables, which are contractual milestone documents, artifacts are granular, technical views of the architecture. Artifacts are created, updated, and curated inside the Architecture Definition Document and Architecture Requirements Specification.
The TOGAF standard categorizes all artifacts into exactly three structural types:
1. Catalogs (Inventories / Lists)
Catalogs are flat or hierarchical lists of architectural building blocks or entities. They provide unambiguous inventories that ensure complete coverage of an architecture domain without showing complex relational webs.
- Characteristics: Tabular or list-based; easy to query, sort, and reconcile against financial portfolios or IT asset management tools.
- Representative Examples:
- Business Architecture: Organization/Actor Catalog, Business Service/Function Catalog, Business Capability Catalog, Goal/Objective Catalog.
- Data Architecture: Data Entity Catalog, Data Component Catalog.
- Application Architecture: Application Portfolio Catalog, Interface Catalog.
- Technology Architecture: Technology Standards Catalog, Technology Portfolio Catalog.
- Requirements & Governance: Principle Catalog, Requirements Catalog.
2. Matrices (Relational Grids)
Matrices are two-dimensional tabular grids that depict relationships, mappings, and cross-dependencies between two distinct entity types (or occasionally between entities of the same type).
- Characteristics: Reveal gaps, overlaps, circular dependencies, and ownership voids. If an entity on one axis has no corresponding marks on the other axis, an architectural gap or redundant asset is immediately exposed.
- Representative Examples:
- Data Entity / Business Function Matrix: Identifies which business functions create, read, update, or delete (CRUD) specific data entities.
- Application / Organization Matrix: Maps which business units and departments utilize specific application components.
- Application / Technology Matrix: Shows which technology components host or run specific application software.
- Value Stream/Capability Matrix: Correlates which organizational capabilities enable specific stages of customer value delivery.
- Application/Data Matrix: Documents which applications use which data entities.
3. Diagrams (Graphical Views)
Diagrams are visual, graphical representations of architectural entities and their structural, behavioral, or physical relationships from a defined viewpoint.
- Characteristics: Highly accessible visual media designed to convey complex flows, boundaries, and dependencies rapidly to human stakeholders.
- Representative Examples:
- Business Architecture: Business Footprint Diagram, Value Stream Map Diagram, Business Process Flow Diagram.
- Data Architecture: Conceptual Data Diagram, Logical Data Diagram, Data Migration Diagram.
- Application Architecture: Application Communication Diagram, Application and User Location Diagram, Software Distribution Diagram.
- Technology Architecture: Environments & Locations Diagram, Platform Decomposition Diagram, Processing Diagram.
Building Blocks: The Engine of Reusable Capabilities
A Building Block is an autonomous, potentially reusable package of business, application, data, or technology capability that can be combined with other building blocks to deliver architectures and operational solutions.
The TOGAF standard establishes a fundamental lifecycle dichotomy between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs):
Architecture Building Blocks (ABBs)
- Nature: Technology-neutral, requirement-oriented, conceptual specifications.
- Focus: Defines what business or technical capability is required, rather than how it will be procured or engineered.
- Attributes: Defines functional requirements, interface requirements, interoperability standards, security attributes, and performance criteria.
- ADM Lifecycle: Conceived in Phase A (Architecture Vision) and elaborated in detail during Phases B, C, and D (Business, Data, Application, and Technology Architectures).
- Example: "Enterprise Single Sign-On and Identity Federation Service with OpenID Connect interface, multi-factor authentication capability, and 99.99% availability SLA."
Solution Building Blocks (SBBs)
- Nature: Technology-specific, implementation-oriented, tangible components.
- Focus: Defines how the architectural requirements captured in the ABB are physically realized.
- Attributes: Represents commercial off-the-shelf (COTS) software products, custom software applications, cloud platform services, hardware specifications, and vendor packages.
- ADM Lifecycle: Explored as candidate solutions in Phase E (Opportunities & Solutions), finalized and procured in Phase F (Migration Planning), and deployed into production in Phase G (Implementation Governance).
- Example: "Okta Customer Identity Cloud SaaS deployment with Duo Security FIDO2 hardware token integration hosted in AWS us-east-1 region."
The ABB-to-SBB Progression Across ADM Phases
Phase A - D: Requirements & Design --> Phase E - F: Selection & Planning --> Phase G: Execution
[ Architecture Building Block (ABB) ] --> [ Candidate / Procured SBB ] --> [ Deployed Operational SBB ]
(Captures WHAT is needed) (Selects HOW it is realized) (Maintains in production)
Comparative Matrix: Deliverables vs. Artifacts vs. Building Blocks
Understanding how these three concepts interlock is the foundation of high scores on the practitioner exam:
| Structural Dimension | Deliverable | Artifact | Building Block (ABB / SBB) |
|---|---|---|---|
| Definition | Formally specified, contractual work product signed off by stakeholders | Granular work product describing an aspect of the architecture | Reusable component of business, IT, or architectural capability |
| Governance Status | Formal decision milestone; approved by Architecture Board | Managed inside deliverables; updated as models evolve | Cataloged in Architecture Repository for enterprise reuse |
| Internal Structure | Contains executive summaries, contracts, and multiple artifacts | Formatted strictly as a Catalog, Matrix, or Diagram | Abstract specification (ABB) or physical realization (SBB) |
| Example | Architecture Definition Document (ADD) | Application Communication Diagram | Customer Relationship Management ABB / Salesforce CRM SBB |
| Primary Purpose | Decision-making, governance sign-off, capital authorization | Communicating specific concerns to targeted stakeholder groups | Assembling scalable, modular enterprise architectures |
Common Exam Traps & Practitioner Pitfalls
- Trap 1: Classifying an Artifact as a Deliverable: Exam distracters frequently refer to the "Application Portfolio Matrix Deliverable." A matrix is an artifact, never a deliverable. The deliverable is the Architecture Definition Document that contains the matrix.
- Trap 2: Believing an ABB Represents Commercial Software: If an exam option states that an ABB is "an enterprise procurement of Microsoft Azure Synapse Analytics," this is strictly false. That is an SBB. ABBs are strictly technology-agnostic functional specifications.
- Trap 3: Confusing Catalogs with Matrices: A catalog is a flat or structured list of single-domain entities (e.g., list of applications). A matrix always correlates two entity types to reveal relationships (e.g., applications mapped against business units).
A lead enterprise architect compiles an Application Communication Diagram, an Application/Organization Matrix, and an Application Portfolio Catalog into a comprehensive dossier submitted to the Architecture Board for formal milestone sign-off. How does the TOGAF Architecture Content Framework classify these individual elements relative to the submitted package?
Each individual item is a formal Deliverable, while the dossier as a whole is an informal Building Block used only for internal reference
The diagram, matrix, and catalog are Artifacts, and the dossier submitted for sign-off is a Deliverable such as the Architecture Definition Document
The diagram and matrix are Solution Building Blocks, while the catalog is an Architecture Building Block that specifies their requirements
All of the elements are Architecture Building Blocks, since anything submitted to the Architecture Board for sign-off becomes an ABB
During Phase B, an architect writes a detailed specification for an 'Automated Identity and Access Federation Engine' outlining interface protocols, encryption standards, and performance SLAs without specifying any commercial product or vendor. In Phase E, the team selects 'PingFederate hosted on Red Hat OpenShift' to realize this capability. How does the TOGAF Standard categorize these two entities?
The Phase B specification is a Solution Building Block, whereas the Phase E selection is an Architecture Building Block that the specification realizes in the target
Both are Architecture Building Blocks, because each one supports the target architecture and is stored in the Architecture Repository
The Phase B specification is an artifact matrix, whereas the Phase E selection is a deliverable contract signed with the vendor
The Phase B specification is an Architecture Building Block (ABB), whereas the Phase E product selection is a Solution Building Block (SBB)
An enterprise architect needs to analyze which business departments have operational dependencies on specific legacy software systems, identifying orphan applications that have no departmental owner. Which type of TOGAF artifact is specifically suited for this two-dimensional relationship mapping?
A Matrix artifact (such as an Application/Organization Matrix)
A Catalog artifact (such as an Application Portfolio Catalog)
A Technology Node Diagram
An Architecture Contract deliverable
Sections you finish are checked off in the contents.