Study guide
13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs)
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs)
Key Takeaways Explain This Topic AI
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.
Last updated: October 2026
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).