Section 1: Content Framework Overview
The Architecture Content Framework provides a structural model for the content produced during architecture work. It classifies all architecture outputs into three components so that deliverables are consistent, reusable, and governable across the enterprise:
- Deliverables — contractual, formally reviewed and signed-off work products produced at defined ADM milestones
- Artifacts — architecture work products (diagrams, catalogs, matrices) embedded within deliverables
- Building Blocks — reusable architecture components described by artifacts and packaged into deliverables
Deliverables CONTAIN artifacts. Artifacts DESCRIBE building blocks. This three-level containment hierarchy is the most tested fact about the Content Framework.
Section 2: Deliverables vs Artifacts vs Building Blocks
| Content Type | Definition | Examples | Signed Off? |
|---|---|---|---|
| Deliverable | Contractual work product formally reviewed at an ADM milestone | Architecture Definition Document, Statement of Architecture Work, Architecture Roadmap, Architecture Contract | Yes — sponsor / Architecture Board |
| Artifact | Specific work product describing an aspect of the architecture; embedded inside a deliverable | Business Capability Catalog, Application Interaction Diagram, Technology Standards Matrix, Stakeholder Map | No — produced during work |
| Building Block | A potentially reusable component of capability that can be combined with others to deliver architectures and solutions | Authentication Service ABB, Active Directory SBB, Data Repository ABB, SQL Server SBB | No — described by artifacts |
The most common Part 1 trap: a diagram, catalog, or matrix is an artifact, not a deliverable. Artifacts are embedded inside deliverables; only deliverables are independently reviewed and signed off. If a question shows "Stakeholder Map" and asks deliverable or artifact — the answer is artifact.
Section 3: Architecture Building Blocks (ABBs)
An Architecture Building Block (ABB) captures the requirements and shape of a capability component needed to deliver the Target Architecture, without specifying how that capability will be implemented.
- Defines WHAT capability is needed
- Technology-agnostic — no vendor or product specified
- Reusable across multiple architectures
- Defined during Phases B, C, and D
- Specified at the logical level
- Authentication Service ABB
- Data Repository ABB
- Message Broker ABB
- Identity Provider ABB
- API Gateway ABB
- Reporting Engine ABB
Section 4: Solution Building Blocks (SBBs)
A Solution Building Block (SBB) represents a specific, implementable component that realises one or more ABBs. SBBs are identified in Phase E when the architect evaluates available products against the logical capability requirements.
- Defines HOW a capability is implemented
- Technology-specific — names a vendor / product
- Selected in Phase E
- Specified at the physical level
- Must conform to the ABB it realises
- Authentication Service ABB → Microsoft Active Directory
- Data Repository ABB → SQL Server / Oracle DB
- Message Broker ABB → Azure Service Bus
- API Gateway ABB → Azure API Management
- Reporting Engine ABB → Power BI Embedded
ABB = WHAT (logical, technology-agnostic, Phases B/C/D). SBB = HOW (physical, technology-specific, Phase E).
One ABB may be realised by multiple SBBs (e.g., different products per environment). SBBs must conform to the ABB they implement.
Section 5: Complete Artifact Catalog by Domain
TOGAF defines three artifact types: Catalogs (lists of things), Matrices (relationships between things), Diagrams (pictures of things). The table below covers all major artifacts by domain.
| Domain | Type | Artifact | What It Shows |
|---|---|---|---|
| Business Phase B | Catalog | Organization / Actor Catalog | Organizational units and roles |
| Catalog | Driver / Goal / Objective Catalog | Business motivations and goals | |
| Catalog | Role Catalog | Business roles and responsibilities | |
| Catalog | Business Service / Function Catalog | Services and functions offered | |
| Catalog | Location Catalog | Geographic locations and sites | |
| Matrix | Business Interaction Matrix | Interactions between organizational units | |
| Matrix | Actor / Role Matrix | Actors mapped to roles | |
| Diagram | Business Footprint Diagram | Driver/goal/objective to org unit and function | |
| Diagram | Business Service / Information Diagram | Business services and information flows | |
| Data Phase C | Catalog | Data Entity / Data Component Catalog | All data entities and components |
| Matrix | Data Entity / Business Function Matrix | CRUD: which functions act on which data | |
| Matrix | Application / Data Matrix | Applications mapped to data they use | |
| Diagram | Conceptual Data Diagram | High-level business data entities and relationships | |
| Diagram | Logical Data Diagram | Detailed logical data model | |
| Diagram | Data Dissemination Diagram | How data moves between applications and stores | |
| Diagram | Data Lifecycle Diagram | Create, read, update, archive, delete lifecycle | |
| Diagram | Data Security Diagram | Data security classifications and access controls | |
| Application Phase C | Catalog | Application Portfolio Catalog | All applications in the enterprise |
| Catalog | Interface Catalog | All application interfaces and integration points | |
| Matrix | Application / Organization Matrix | Applications mapped to organizational units | |
| Matrix | Role / Application Matrix | Business roles mapped to applications used | |
| Diagram | Application Communication Diagram | Application-to-application communications | |
| Diagram | Application and User Location Diagram | Applications and users by geographic location | |
| Diagram | Application Use-Case Diagram | Application interactions with actors | |
| Technology Phase D | Catalog | Technology Standards Catalog | Technology standards and approved products |
| Catalog | Technology Portfolio Catalog | Full technology portfolio of the enterprise | |
| Matrix | Application / Technology Matrix | Applications mapped to technology components | |
| Diagram | Environments and Locations Diagram | Technology deployments by environment and location | |
| Diagram | Platform Decomposition Diagram | Technology platform components and relationships | |
| Diagram | Network Computing / Hardware Diagram | Network topology and hardware components | |
| Cross-Domain | Diagram | Architecture Vision Diagram | High-level overview across all domains (Phase A) |
| Diagram | Stakeholder Map | Stakeholders, concerns, and relationships (Phase A) | |
| Catalog | Architecture Principles Catalog | All architecture principles (Preliminary) | |
| Diagram | Solution Concept Diagram | Proposed solution overview (Phase A / Phase E) |
Catalog = list. Matrix = relationship grid. Diagram = picture. Part 1 may present a scenario and ask which artifact type is appropriate. "Show which applications use each data entity" = Application/Data Matrix (not a diagram). "Show how data moves between systems" = Data Dissemination Diagram.
Section 6: Content Metamodel
The Content Metamodel formally defines the entity types, properties, and relationships of building blocks used in the framework. It provides a schema ensuring all building blocks are described consistently across the Architecture Repository.
| Entity Type | Description | Examples |
|---|---|---|
| Actor | Person, organisation, or system that initiates or interacts with activities | Customer, IT Department, External Partner |
| Role | Behaviour of an actor in a specific context | Order Processor, Data Steward, System Administrator |
| Business Service | Externally-visible unit of business capability | Order Fulfilment Service, Customer Onboarding |
| Function | Recurring activity that delivers business capabilities | Accounts Payable Processing, Risk Assessment |
| Data Entity | Encapsulation of data meaningful to the business | Customer, Order, Product, Invoice |
| Application Component | Encapsulation of application functionality aligned to implementation units | CRM System, ERP Module, Payment Gateway |
| Technology Component | Encapsulation of technology infrastructure | Web Server, Database Server, Load Balancer |
The metamodel is extensible — organisations may add entity types, properties, and relationships (e.g., adding "Regulation" or "Risk" entities) to suit their domain. Extensions must be governed: approved by the Architecture Board and recorded in the Architecture Repository's Governance Log. Ad-hoc extension without governance produces inconsistency across the repository.
Section 7: Key Deliverables by ADM Phase
Every ADM phase produces formal deliverables — contractually specified work products reviewed and signed off at milestones.
| Phase | Primary Deliverables |
|---|---|
| P Preliminary | Tailored Architecture Framework; Architecture Principles; Governance Framework; Architecture Repository (established) |
| A Architecture Vision | Statement of Architecture Work; Architecture Vision; Stakeholder Map; Architecture Definition Document (shell); Communications Plan |
| B Business Architecture | Architecture Definition Document (Business sections); Gap Analysis — Business; Architecture Requirements Specification (updated) |
| C Information Systems | Architecture Definition Document (Data + Application sections); Gap Analysis — Data; Gap Analysis — Application |
| D Technology Architecture | Architecture Definition Document (Technology section — completed); Gap Analysis — Technology; Architecture Requirements Specification (final) |
| E Opportunities & Solutions | Draft Architecture Roadmap; Implementation and Migration Plan (draft); Work Package list; Transition Architecture definitions |
| F Migration Planning | Finalised Architecture Roadmap; Finalised Implementation and Migration Plan; Prioritised Work Packages; Confirmed Transition Architectures |
| G Implementation Governance | Architecture Contracts; Compliance Assessments; Change Requests; Architecture-compliant solution deliverables |
| H Architecture Change Mgmt. | Architecture Updates; Assessed Change Requests; ADM cycle trigger decision; Updated Architecture Roadmap |
| RM Requirements Mgmt. | Requirements Repository (maintained); Requirements Impact Assessments; Prioritised requirements fed into all phases |
The Architecture Definition Document (ADD) is a single deliverable that grows across four phases: shell in Phase A → Business content in Phase B → Data/Application content in Phase C → Technology content in Phase D. Do NOT confuse it with the Statement of Architecture Work, which is the Phase A authorisation to proceed (scope and approach), not the architecture content itself.
Section 8: Exam-Critical — ABB vs SBB Distinction
Part 1 questions on ABBs and SBBs follow predictable patterns. Study these scenarios:
| Scenario / Stem | Answer | Reasoning |
|---|---|---|
| Capability "Authentication Service" documented with no product named | ABB | Technology-agnostic, logical, defines WHAT |
| "Microsoft Active Directory" selected to fulfil authentication | SBB | Named product, physical, defines HOW |
| Which building block type is defined in Phases B, C, D? | ABB | Architecture phases define logical requirements |
| Which building block type is selected in Phase E? | SBB | Phase E evaluates solutions and picks products |
| "Oracle Database 19c deployed in the production data centre" | SBB | Named product, specific version, deployment context = physical SBB |
| Organisation wants building blocks reusable across different vendor environments | ABB first | ABBs are vendor-agnostic; different SBBs can realise the same ABB in each environment |
Section 9: Revision Summary
Revision Summary — Chapter 12
- The Content Framework has three components: Deliverables (contractual, signed off), Artifacts (work products within deliverables — catalogs, matrices, diagrams), Building Blocks (reusable components described by artifacts).
- Hierarchy: Deliverables CONTAIN artifacts; artifacts DESCRIBE building blocks. Memorise in both directions.
- An artifact is NOT a deliverable. Artifacts are never independently signed off — they live inside deliverables.
- Three artifact types: Catalog = list of things; Matrix = relationship between things; Diagram = picture of things.
- ABB: defines WHAT, technology-agnostic, logical level, defined in Phases B/C/D.
- SBB: defines HOW, technology-specific, physical level, selected in Phase E. One ABB can be realised by multiple SBBs.
- Content Metamodel core entities: Actor, Role, Business Service, Function, Data Entity, Application Component, Technology Component. The metamodel is extensible under governance.
- The Architecture Definition Document is one deliverable built progressively across Phases A–D, not a separate document per phase.
- Statement of Architecture Work (Phase A) = authorisation to proceed. Architecture Definition Document (Phases A–D) = the architecture content itself.
Practice Questions
Five exam-style questions covering Chapter 12. Click a question to reveal the answer and explanation.
A. Deliverable B. Artifact C. Architecture Building Block D. Solution Building Block
Explanation: The Application Communication Diagram is an artifact — specifically a diagram-type artifact in the Application domain (Phase C). It is not a deliverable (never independently reviewed and signed off; it is embedded inside the Architecture Definition Document). It is not a building block. Option B is correct.
A. An Architecture Building Block (ABB) B. A Solution Building Block (SBB) C. An Artifact D. A Deliverable
Explanation: An ABB defines what capability is needed at a logical, technology-agnostic level. "Message Broker" with no vendor specification is a classic ABB. An SBB (Option B) would name a specific product such as "Apache Kafka" or "Azure Service Bus". Option A is correct.
A. Business Capability Catalog B. Application / Data Matrix C. Architecture Definition Document D. Platform Decomposition Diagram
Explanation: The Architecture Definition Document is a deliverable — formally reviewed and signed off by the Architecture Board or sponsor at defined ADM milestones. Options A, B, and D are all artifacts (a catalog, a matrix, and a diagram respectively). Artifacts are embedded within deliverables but are never subject to independent formal sign-off. Option C is correct.
A. Phase B — Business Architecture B. Phase D — Technology Architecture C. Phase E — Opportunities and Solutions D. Phase G — Implementation Governance
Explanation: SBBs are identified and selected in Phase E — Opportunities and Solutions, when the architect evaluates available products against the ABBs defined in Phases B, C, and D. Phase E is specifically where the "how" is decided. ABBs (not SBBs) are defined in Phases B, C, and D. Phase G governs conformance, not building block selection. Option C is correct.
A. Data Entity / Data Component Catalog B. Data Entity / Business Function Matrix C. Logical Data Diagram D. Data Lifecycle Diagram
Explanation: The Data Entity / Business Function Matrix (Option B) maps relationships between two sets of things (data entities and business functions), which is exactly what a matrix artifact is designed for. A Catalog (A) simply lists data entities. A Logical Data Diagram (C) shows data model structure, not CRUD relationships. A Data Lifecycle Diagram (D) shows the create-to-delete lifecycle over time, not the function-to-entity mapping. Option B is correct.