What is the Content Framework?
The TOGAF Architecture Content Framework provides a structural model for architectural content. It defines:
- What types of artifacts should be produced
- How those artifacts relate to each other
- Where they fit in the overall architecture
Think of it as the "data model" for your architecture practice.
The Three Categories
1. Deliverables
Definition: Work products that are contractually specified and reviewed, agreed, and signed off by stakeholders.
Characteristics:
- Formally reviewed and approved
- May be contractual obligations
- Archived for future reference
Examples:
| Deliverable | Purpose | |-------------|---------| | Architecture Definition Document | Contains core architectural artifacts | | Architecture Requirements Specification | Documents requirements across domains | | Architecture Roadmap | Prioritized list of projects | | Transition Architecture | Intermediate states | | Architecture Vision | High-level aspirational view |
2. Artifacts
Definition: Architectural work products that describe an aspect of the architecture.
Characteristics:
- Building blocks of deliverables
- Various formats (catalogs, matrices, diagrams)
- Created and maintained throughout ADM
Artifact Types:
| Type | Description | Example | |------|-------------|---------| | Catalogs | Lists of things | Application Catalog, Technology Standards Catalog | | Matrices | Relationships between things | Application/Data Matrix, Business Interaction Matrix | | Diagrams | Visual representations | Business Process Flow, Application Communication Diagram |
3. Building Blocks
Definition: Potentially reusable components of business, IT, or architectural capability.
Two Types:
Architecture Building Blocks (ABBs):
- Define required functionality and capability
- Technology-agnostic
- Guide solution development
Solution Building Blocks (SBBs):
- Define specific implementations
- Technology-specific
- Purchased or built components
Example: ABB "Customer Identity Management Capability" → implemented by SBB "Microsoft Entra ID" or "Okta"
The Content Metamodel
The metamodel defines entities and relationships across the four architecture domains:
Business Architecture Entities
| Entity | Description | |--------|-------------| | Organization Unit | Organizational structures | | Actor | Person or organization that performs behavior | | Role | Behavior performed by an actor | | Business Service | Service delivered to customers | | Business Process | Sequence of activities | | Business Function | Ongoing business operation | | Business Capability | What the business does (not how) |
Data Architecture Entities
| Entity | Description | |--------|-------------| | Data Entity | Encapsulation of data | | Logical Data Component | Grouping of data entities | | Physical Data Component | Actual data storage |
Application Architecture Entities
| Entity | Description | |--------|-------------| | Logical Application Component | Application functionality encapsulation | | Physical Application Component | Deployed application | | Information System Service | Service provided by applications |
Technology Architecture Entities
| Entity | Description | |--------|-------------| | Technology Service | Technical capability required | | Logical Technology Component | Technology functionality grouping | | Physical Technology Component | Specific technology product | | Platform Service | Infrastructure service |
Entity Relationships
The power of the metamodel is in showing relationships:
Business Service → supported by → Information System Service → provided by → Logical Application Component → realized by → Physical Application Component → hosted on → Logical Technology Component → realized by → Physical Technology Component
Core Content Artifacts by Domain
Business Architecture
Catalogs: Organization/Actor Catalog, Role Catalog, Business Service/Function Catalog
Matrices: Business Interaction Matrix, Actor/Role Matrix
Diagrams: Business Footprint Diagram, Business Service/Information Diagram, Functional Decomposition Diagram, Goal/Objective/Service Diagram, Business Use-Case Diagram, Organization Decomposition Diagram, Process Flow Diagram
Data Architecture
Catalogs: Data Entity/Data Component Catalog
Matrices: Data Entity/Business Function Matrix, Application/Data Matrix
Diagrams: Conceptual Data Diagram, Logical Data Diagram, Data Dissemination Diagram, Data Lifecycle Diagram, Data Security Diagram, Data Migration Diagram
Application Architecture
Catalogs: Application Portfolio Catalog, Interface Catalog
Matrices: Application/Organization Matrix, Role/Application Matrix, Application/Function Matrix, Application Interaction Matrix
Diagrams: Application Communication Diagram, Application and User Location Diagram, Application Use-Case Diagram, Enterprise Manageability Diagram, Process/Application Realization Diagram, Software Engineering Diagram, Application Migration Diagram, Software Distribution Diagram
Technology Architecture
Catalogs: Technology Standards Catalog, Technology Portfolio Catalog
Matrices: Application/Technology Matrix
Diagrams: Environments and Locations Diagram, Platform Decomposition Diagram, Processing Diagram, Networked Computing/Hardware Diagram, Communications Engineering Diagram
Practical Application
Example: Building Block Approach
Scenario: Designing customer identity management
Step 1: Define ABB (Architecture Building Block)
ABB: Customer Identity Management
- Required Capabilities: User registration, Authentication (MFA support), Single Sign-On, Password management, Session management
- Constraints: Must support SAML 2.0, Must support OAuth 2.0, 99.9% availability required
- Interfaces: User-facing login portal, Admin management console
Step 2: Select SBB (Solution Building Block)
SBB Options Analysis:
| Capability | Microsoft Entra ID | Okta | Auth0 | |------------|-------------------|------|-------| | User Registration | ✓ | ✓ | ✓ | | MFA | ✓ | ✓ | ✓ | | SSO | ✓ | ✓ | ✓ | | Cost/user/month | $6 | $8 | $7 |
Selected SBB: Microsoft Entra ID (best ecosystem fit)
Exam Tips
Key Concepts:
- Deliverables vs. Artifacts vs. Building Blocks - Know the differences
- ABB vs. SBB - Architecture (what) vs. Solution (how)
- Catalogs, Matrices, Diagrams - Three types of artifacts
- Metamodel entities - Know main entities per domain
Common Questions:
- "What is the difference between ABB and SBB?" → ABB is technology-agnostic requirement, SBB is specific implementation
- "Which artifact type shows relationships?" → Matrices
- "What are the three categories in the Content Framework?" → Deliverables, Artifacts, Building Blocks
Key Takeaway
The Content Framework provides structure for architecture outputs. Understanding the metamodel helps you create coherent, traceable architectures where business requirements can be traced through to technology implementations. ABBs provide reusable requirements while SBBs provide reusable solutions - together they accelerate architecture development.