Demystifying TOGAF 10: A Step-by-Step Guide to Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs)

In the complex world of Enterprise Architecture, clarity is paramount. One of the most critical concepts in the TOGAF 10 standard is the distinction between what an organization needs and how it gets it. This distinction is captured through the concept of Building Blocks. This tutorial will walk you through the visual logic of Architecture Building Blocks (ABBs) versus Solution Building Blocks (SBBs), helping you visualize the transition from abstract strategy to concrete implementation.

The Core Concept: Reusable Components

At the heart of TOGAF 10, Building Blocks are defined as reusable components of an architecture. Imagine them as the Lego bricks of your digital ecosystem. Just as you can build different structures with the same bricks, an enterprise can use the same architectural blocks to solve various problems.

However, not all bricks are created equal. The framework divides these blocks into two distinct categories:

• Architecture Building Blocks (ABBs): The “What”.
• Solution Building Blocks (SBBs): The “How”.

1. Architecture Building Blocks (ABBs): The “What is Needed”

ABBs describe the capabilities or architectural structures needed by the organization. They are high-level and abstract. They represent the functional requirements and the strategic direction without specifying a specific vendor or product.

Key Characteristics of ABBs

1. Capsule Capabilities: They define a specific capability the business needs (e.g., “Customer Identity Management”).
2. Structural Focus: They describe the necessary architecture patterns or structures.
3. Service Needs: They outline what services are required to bridge gaps.

In the context of the diagram, look at the blue “Capability” block or the “Structure” block. These are the definitions. If you are a business analyst, you are defining the ABB. You are answering the question: “What capability do we need to achieve our strategy?”

2. Solution Building Blocks (SBBs): The “How it is Implemented”

Once the ABB is defined, we move to the Solution Building Blocks. SBBs describe implementable components such as applications, platforms, products, or services. These are the concrete artifacts that engineers and developers actually deploy.

Key Characteristics of SBBs

1. Concrete Implementation: This is a specific software application (e.g., “Salesforce CRM”).
2. Platform Specific: It refers to a specific technology stack or cloud platform.
3. Product & Service: It includes purchased products or third-party services.

In the visual model, the SBB is represented by the green “Toolbox” icon. This is where the rubber meets the road. When the diagram shows “Compose” or “Implement,” it is referring to the selection and deployment of SBBs.

Visualizing the Relationship: The Architecture Pyramid

The central image in the source material depicts a pyramid representing the layers of Enterprise Architecture: Strategy, Business, Data, Application, and Technology.

• Reuse (Blue Arrow): The ABBs feed into the pyramid. We define a capability (ABB) and reuse it across the Business and Data layers.
• Compose (Green Arrow): We compose Solution Building Blocks to fill the Application and Technology layers.
• Implement (Orange Arrow): The final result is the implementation of the Solution Building Blocks that deliver the Architecture Building Blocks.

This flow ensures that your technical implementation (SBB) is always directly aligned with your strategic goals (ABB). You don’t just buy software; you buy software that solves a specific architectural need.

Worked Example: Customer Identity Management

To make this concrete, let’s look at the “Worked Example” provided in the visual guide.

Step 1: The Architecture Building Block (Abstract)

Requirement: The organization needs to manage who its customers are securely.

ABB: “Customer Identity Management.”

Note: This block is abstract. It does not say which software to use. It simply states the capability that must exist.

Step 2: The Solution Building Block (Concrete)

Implementation: The enterprise selects a specific vendor product to deliver that capability.

SBB: “Specific Identity Platform (e.g., Okta, Azure AD, or PingIdentity).”

Note: This block is concrete. It is a product that can be installed, configured, and run.

The arrow between them represents the mapping. The SBB “delivers” the ABB. The specific platform provides the capability of identity management.

Recommended Tooling for Architecture Modeling

Visualizing these relationships is essential for effective communication between stakeholders. To model these diagrams effectively and adhere to TOGAF standards, professional tooling is required.

For architects looking to create robust diagrams like the one discussed here, the Recommended tooling of Visual Paradigm TOGAF ADM Tool is an industry-leading choice. Visual Paradigm offers a dedicated suite for the TOGAF Architecture Development Method (ADM), allowing users to:

• Drag and drop standard TOGAF artifacts.
• Automatically link ABBs to SBBs to trace requirements.
• Generate comprehensive documentation based on your models.

Conclusion

Understanding the distinction between ABBs and SBBs is the key to successful enterprise architecture. By keeping the “What” (ABB) separate from the “How” (SBB), organizations maintain flexibility. They can change their specific technology stack (SBB) without changing their core capabilities (ABB). This abstraction is the foundation of a resilient and adaptable enterprise.