1.3 Core Concepts: Enterprise, Architecture, Deliverables, Artifacts, and Building Blocks
Key Takeaways
- A Deliverable is a contractually specified architectural work product formally reviewed, agreed upon, and signed off by stakeholders.
- An Artifact is an architectural view describing an aspect of the architecture, categorized into Catalogs (lists), Matrices (grids), and Diagrams (visuals).
- Artifacts form the detailed content inside composite Deliverables such as the Architecture Definition Document (ADD).
- Architecture Building Blocks (ABBs) specify vendor-agnostic capability requirements ('WHAT'), while Solution Building Blocks (SBBs) define concrete physical implementations ('HOW').
- ABBs are defined in early ADM phases, whereas SBBs are selected and procured in later phases like Opportunities & Solutions (Phase E).
1.3 Core Concepts: Enterprise, Architecture, Deliverables, Artifacts, and Building Blocks
To successfully execute architectural governance and construct enterprise blueprints, architects must master the precise terminology defined in the TOGAF Content Framework. A frequent source of confusion in enterprise architecture practice is distinguishing between Deliverables, Artifacts, and Building Blocks. TOGAF provides clear, unambiguous definitions for each construct.
1. Deliverables: Contractual Architecture Work Products
In TOGAF, a Deliverable is a formal, contractually specified work product that is reviewed, agreed upon, and signed off by key stakeholders.
Deliverable Definition: A work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders.
Key Characteristics of Deliverables:
- Formal Sign-off Required: Deliverables represent major milestones in the Architecture Development Method (ADM) and require formal governance review and stakeholder approval.
- Contractual & Binding: They represent the agreed output of an architectural phase or engagement (e.g., between the Enterprise Architecture team and executive sponsors).
- Composite Containers: Deliverables typically contain multiple architectural Artifacts along with supporting text, executive summaries, management recommendations, and governance documentation.
Primary Examples of TOGAF Deliverables:
- Architecture Vision: Executive overview of the target enterprise architecture, business goals, and strategic constraints produced in ADM Phase A.
- Architecture Definition Document (ADD): The comprehensive technical and business blueprint documenting Baseline and Target Architectures across BDAT domains.
- Architecture Requirements Specification: Quantitative and qualitative requirements driving the architectural design (e.g., performance metrics, compliance targets, SLA specifications).
- Statement of Architecture Work: The formal agreement/contract between the architecture organization and the sponsoring business unit defining scope, budget, resources, and deliverables.
2. Artifacts: Catalogs, Matrices, and Diagrams
An Artifact is an architectural work product that describes a specific view or aspect of the overall architecture. Artifacts form the structured content inside Deliverables.
Artifact Definition: An architectural work product describing an aspect of the architecture.
TOGAF categorizes all Artifacts into three primary structural formats:
| Artifact Format | Purpose & Description | Primary Structural Characteristics | Key Examples |
|---|---|---|---|
| Catalogs | Lists or inventories of architectural elements/entities. | Flat or hierarchical tabular lists; no explicit relationship mapping shown. | Application Portfolio Catalog, Business Function Catalog, Principles Catalog, Requirements Catalog. |
| Matrices | Grids illustrating relationships between two or more architectural entities. | Two-dimensional matrices (rows vs. columns) showing intersections, mappings, or dependencies. | Business Interaction Matrix, Application/Function Matrix, System/Data Matrix, Role/Organization Matrix. |
| Diagrams | Visual representations and graphical views of architectural models. | Node-and-edge diagrams, flowcharts, topology drawings, and sequence diagrams. | Business Footprint Diagram, Application Communication Diagram, Technology Portfolio Diagram, Processing Diagram. |
3. Building Blocks: ABBs vs. SBBs
A Building Block is a reusable component of business, IT, or architectural capability that can be combined with other building blocks to deliver enterprise solutions and architectures.
Building Block Definition: A package of functionality defined to meet business needs across an enterprise, representing a reusable capability.
TOGAF makes a critical distinction between two types of building blocks: Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).
Architecture Building Blocks (ABBs)
- Specification-Focused: ABBs define the functionality, requirements, and boundary specifications required by the architecture.
- Vendor-Agnostic: ABBs do not reference specific products, commercial brands, or underlying physical implementations.
- Phase Placement: ABBs are defined and refined during early ADM phases (Phases A, B, C, and D).
- Example: An ABB titled "Relational Database Management System (RDBMS) Capability" specifying ACID compliance, SQL-2016 support, multi-region replication, and AES-256 encryption.
Solution Building Blocks (SBBs)
- Implementation-Focused: SBBs represent the actual physical components, products, software packages, or operational services used to realize an ABB.
- Vendor & Component Specific: SBBs specify exact products, technologies, and vendor solutions.
- Phase Placement: SBBs are selected and procured during later ADM phases (Phase E: Opportunities & Solutions and Phase F: Migration Planning).
- Example: An SBB titled "PostgreSQL 15 Enterprise Cluster hosted on AWS RDS Multi-AZ", which realizes the abstract RDBMS ABB specification.
Summary Comparison: Deliverables, Artifacts, and Building Blocks
To consolidate understanding for enterprise governance and exam preparation, the table below highlights the distinctions across all core TOGAF constructs:
| Construct | Primary Purpose | Key Attribute | Governance Status | Typical Example |
|---|---|---|---|---|
| Deliverable | Formal work product for executive stakeholders. | Contractual, binding container. | Formally reviewed and signed off. | Architecture Vision, Architecture Definition Document (ADD). |
| Artifact | Architectural view describing a specific domain aspect. | Catalog (list), Matrix (grid), or Diagram (visual). | Embedded within deliverables for architectural review. | Application/Function Matrix, Business Footprint Diagram. |
| ABB | Abstract specification of an architectural requirement. | Vendor-agnostic, capability-focused ("WHAT"). | Guides candidate solution selection during ADM. | Identity & Access Management (IAM) Specification ABB. |
| SBB | Realized candidate solution or commercial product. | Vendor-specific, physical component ("HOW"). | Procured, built, deployed, and operationally governed. | Okta Identity Cloud SBB, Oracle 19c Enterprise Database SBB. |
What is the key distinction between a Deliverable and an Artifact in TOGAF?
Which statement correctly describes the difference between an Architecture Building Block (ABB) and a Solution Building Block (SBB)?
What are the three primary structural formats of Artifacts defined in the TOGAF Content Framework?