8.1 Architecture Content Framework Overview & Deliverables vs Artifacts vs Building Blocks

Architecture Content Framework Overview & Architectural Work Products

In enterprise architecture, consistency, clarity, and standardization are paramount. Without a structured content model, different architectural teams within the same enterprise risk producing incompatible deliverables, using conflicting terminology, and duplicating effort. The TOGAF Architecture Content Framework addresses these challenges by providing a structural model and taxonomy for categorizing, creating, storing, and reusing all architectural work products.

The Content Framework was introduced in TOGAF 9 (2009) and is carried forward in the 10th Edition inside the Architecture Content document, where it now sits alongside the Enterprise Metamodel. It acts as the detailed structural companion to the Architecture Development Method (ADM). While the ADM describes what to do (the process steps and iterative phases), the Content Framework defines what to produce (the structural artifacts, outputs, and underlying building blocks).

---

Rationale & Motivation for a Content Framework

Before the adoption of a formal content framework, enterprise architecture initiatives frequently suffered from common systemic flaws:

1. Inconsistent Outputs: Architectural teams produced ad-hoc documents, diagrams, and spreadsheets that lacked common schemas, making cross-domain analysis nearly impossible.
2. Poor Tool Interoperability: Architecture repository tools, modeling platforms, and governance suites could not exchange data cleanly because entity definitions and relationship mappings were undefined.
3. Limited Reusability: Architectural assets created in one project could rarely be leveraged in another because building blocks were embedded inside static, monolithic documents.
4. Unclear Governance & Sign-Off: Stakeholders struggled to distinguish between high-level contractual commitments and granular background design views.

The Architecture Content Framework solves these issues by establishing a precise taxonomy that categorizes every work product produced during ADM execution into three distinct architectural constructs: Deliverables, Artifacts, and Building Blocks.

---

The Three Categories of Architectural Work Products

To ensure architectural outputs are effectively governed, communicated, and reused, TOGAF categorizes all work products according to their purpose, lifecycle, and audience.

+-----------------------------------------------------------------------+
|                             DELIVERABLE                               |
|   (Formal, contractually specified, signed-off output package)        |
|                                                                       |
|   +---------------------------------------------------------------+   |
|   |                          ARTIFACT                             |   |
|   |   (Architectural View: Catalog, Matrix, or Diagram)          |   |
|   |                                                               |   |
|   |   +-------------------------------------------------------+   |   |
|   |   |                   BUILDING BLOCK                      |   |   |
|   |   |   (Reusable asset: ABB or SBB component)              |   |   |
|   |   +-------------------------------------------------------+   |   |
|   +---------------------------------------------------------------+   |
+-----------------------------------------------------------------------+

1. Deliverables

A Deliverable is a formal, contractually specified output work product that is agreed upon, reviewed, and signed off by project stakeholders. Deliverables represent the formal documentation generated throughout an ADM project lifecycle and are typically tracked in project management plans.

Key Characteristics of Deliverables:

• Formal Approval: Requires explicit stakeholder review, governance sign-off, and formal change control.
• Contractual Nature: Forms the baseline agreement between the architecture team, business sponsors, and implementation teams.
• Composite Structure: A deliverable is rarely a single diagram; it is usually a structured document, executive deck, or repository snapshot containing multiple supporting artifacts.
• Examples:
  • Architecture Vision (Phase A)
  • Architecture Definition Document (Phases B, C, D)
  • Architecture Requirements Specification (Phases B, C, D)
  • Statement of Architecture Work (Phase A)
  • Transition Architecture Plan (Phase E/F)

2. Artifacts

An Artifact is a finer-grained architectural work product that describes a specific aspect or view of the architecture. Artifacts are the individual visual and tabular representations used to populate deliverables and communicate specific architectural concerns to targeted stakeholder groups.

TOGAF categorizes all artifacts into exactly three structural representation types:

1. Catalogs: Tabular lists or registries of building blocks of a specific type (e.g., Business Capability Catalog, Application Portfolio Catalog, Technology Standards Catalog). Catalogs provide the raw baseline inventory of assets.
2. Matrices: Two-dimensional grids mapping relationships between two entity types (e.g., Business Function / Data Entity Matrix, Application / Organization Matrix). Matrices highlight dependencies, gap analysis, and cross-domain alignment.
3. Diagrams: Visual graphical views illustrating topology, interaction flows, structural hierarchies, and physical deployments (e.g., Business Footprint Diagram, Application Communication Diagram, Technology Infrastructure Diagram).

Key Characteristics of Artifacts:

• Viewpoint-Driven: Designed specifically to answer stakeholder queries and address architectural concerns.
• Reusable Views: Can be extracted, updated, and recombined into different deliverables across multiple ADM iterations.
• Non-Contractual in Isolation: While artifacts are packaged inside deliverables for sign-off, an individual artifact is an architectural view rather than a standalone contract.

3. Building Blocks

A Building Block is an autonomous, reusable component of business, application, data, or technology capability that can be combined with other building blocks to deliver enterprise architecture solutions.

Building blocks represent the actual constituent elements of the enterprise. They exist at two operational levels:

• Architecture Building Blocks (ABBs): Conceptual and vendor-agnostic specifications of requirements and capabilities (e.g., Customer Relationship Management ABB, Relational Database Management System ABB).
• Solution Building Blocks (SBBs): Concrete, physical realizations and products selected to implement ABBs (e.g., Salesforce Sales Cloud, PostgreSQL 15.2).

Key Characteristics of Building Blocks:

• High Reusability: Stored in the Enterprise Architecture Repository for reuse across multiple initiatives.
• Interoperable: Defined with explicit interfaces and boundaries to allow modular substitution.
• Evolutionary: Evolve through the ADM lifecycle from abstract requirement specifications (ABBs) to physical implementations (SBBs).

---

Structural Hierarchy & Packaging

The relationship between these three constructs forms a logical nesting hierarchy:

• Building Blocks are the fundamental assets and capabilities of the enterprise.
• Artifacts (Catalogs, Matrices, Diagrams) organize and present Building Blocks into meaningful views.
• Deliverables package related Artifacts and narrative content into formal governance documents for sign-off.

By strictly enforcing this content taxonomy, the TOGAF Architecture Content Framework enables organizations to establish a robust Architecture Repository, streamline governance, and foster true architectural asset reuse.