In the realm of Enterprise Architecture, structure is everything. Without a defined framework, architectural efforts can easily become disjointed, leading to redundant work and unclear communication. The TOGAF Architecture Content Framework is the backbone that organizes these efforts, defining exactly what architects produce. This tutorial will break down the three primary pillars of this framework—Deliverables, Artifacts, and Building Blocks—and explain how they interact to create a cohesive enterprise architecture.

1. The Core Concept: The Architecture Content Framework

The Architecture Content Framework is not just a list of documents; it is a structured model that defines the “what” of architecture. It ensures that every stakeholder understands the scope of the work. As illustrated in the visual reference, the framework is divided into three distinct but interconnected categories:

• Deliverables: The formal outputs.
• Artifacts: The detailed views and data.
• Building Blocks: The reusable components.

Understanding these three areas is essential for any architect looking to implement a robust architecture development method (ADM).

2. Pillar One: Deliverables

Deliverables represent the tangible, formal outputs of the architecture process. These are the documents and plans that are reviewed, approved, and signed off by stakeholders. They serve as the legal and contractual agreements between the business and the technology teams.

Key Deliverables Defined:

• Architecture Definition Document (ADD): The primary document that summarizes the architecture. It contains the high-level business, data, application, and technology architecture.
• Architecture Requirements Specification: This document defines the constraints, non-functional requirements, and business needs that the architecture must satisfy.
• Implementation and Migration Plan: A roadmap detailing how the organization will transition from the current state (Baseline) to the future state (Target), often broken down into phases.
• Architecture Contract: A formal agreement between the architecture team and the implementation team, defining the scope and responsibilities of the work to be done.

Tutor’s Note: Think of Deliverables as the “Report Cards.” They are the approved outputs that prove the work has been done according to the requirements.

3. Pillar Two: Artifacts

If Deliverables are the reports, Artifacts are the raw materials and detailed views used to construct those reports. Artifacts provide the granular details required to build the architecture. They are the building blocks of information that architects manipulate to create the Deliverables.

The TOGAF framework categorizes artifacts into three specific types:

A. Catalogs

A catalog is essentially a list of items. It is a structured list of architectural building blocks that exist within a specific domain. For example, an Application Catalog would list every application currently in use by the organization.

B. Matrices

A matrix is a two-dimensional grid used to show relationships between items. It helps architects visualize connections that might be missed in a linear list. Common examples include:

• Actor-Role Matrix: Shows which users (actors) perform which roles.
• Application-Process Matrix: Shows which applications support which business processes.

C. Diagrams

Diagrams are the visual representations of the architecture. They are crucial for communicating complex technical concepts to non-technical stakeholders. Examples include:

• Process Flows: Showing how work moves through the organization.
• Component Diagrams: Showing how software components interact.

Tutor’s Note: Artifacts are the “Ingredients.” You use catalogs, matrices, and diagrams to inform your decisions and build your deliverables.

4. Pillar Three: Building Blocks

The final pillar of the framework focuses on Building Blocks (BBs). These are the reusable components that make up the actual solution. The framework distinguishes between two types of blocks:

Architecture Building Blocks (ABBs)

ABBs are logical components. They represent the functionality required but are vendor-independent. They define what is needed, not how it will be implemented technically.

• Example: “Customer Management Service” (The logical requirement).

Solution Building Blocks (SBBs)

SBBs are physical implementations. These are the specific products, hardware, or software solutions that are procured or built to fulfill the logical requirements of the ABBs.

• Example: “Salesforce CRM” (The specific tool used to solve the requirement).

The relationship between ABBs and SBBs is critical: ABBs inform the selection of SBBs. You define the logical requirement first, then find the physical solution that fits.

5. The Content Metamodel

Beyond these three pillars, the framework relies on a Content Metamodel. This is the underlying data structure that defines relationships between architectural elements across different domains. It ensures that when you define a Business Actor, you can link it to a Data Entity, which is then managed by an Application, running on Technology.

Conclusion

Mastering the TOGAF Architecture Content Framework is the key to producing consistent, high-quality architecture. By clearly separating Deliverables (the approved outputs), Artifacts (the detailed views), and Building Blocks (the logical and physical components), architects can ensure that their work is structured, reusable, and aligned with business goals. The framework provides a vocabulary and a structure that allows complex systems to be broken down into manageable parts.

To effectively implement this framework, leveraging the right tools is essential. While spreadsheets and drawing tools can handle the basics, a comprehensive architecture tool is required to maintain the integrity of the metamodel and manage the relationships between artifacts and building blocks. For this purpose, the Recommended tooling of Visual Paradigm TOGAF Tool is highly suggested. Visual Paradigm offers robust support for the TOGAF Content Framework, allowing you to automatically generate diagrams, manage catalogs and matrices, and track the relationships between your ABBs and SBBs, ensuring that your architecture remains consistent and up-to-date throughout the development lifecycle.