8.2 Architecture Building Blocks (ABBs) vs Solution Building Blocks (SBBs)

Architecture Building Blocks (ABBs) vs Solution Building Blocks (SBBs)

A core strength of TOGAF is its modular, component-based approach to enterprise architecture. Central to this approach is the concept of Building Blocks. A building block is a package of functionality defined to meet business needs across an enterprise. TOGAF makes a fundamental distinction between two types of building blocks throughout the Architecture Development Method (ADM) lifecycle: Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).

Understanding the distinction between specification (ABBs) and realization (SBBs) prevents organizations from locking into specific vendor products prematurely, ensuring that business requirements drive technical solutions rather than technology constraints dictating business capability.

---

Architecture Building Blocks (ABBs): Specification of Requirement

Architecture Building Blocks (ABBs) represent the abstract specification of architecture requirements, business capabilities, application services, and technology boundaries. ABBs define what functionality is needed without specifying how that functionality will be physically implemented or which vendor product will be purchased.

Key Characteristics of ABBs:

• Vendor-Agnostic: Free from proprietary vendor dependencies, specific software brands, or hardware models.
• Requirement-Driven: Capture business requirements, directional strategy, interoperability rules, and functional interfaces.
• Logical Granularity: Define logical entities such as "Customer Relationship Management System", "Enterprise Service Bus", or "Relational Database Management System".
• Phase Origin: ABBs are identified, defined, and refined during the early architectural definition phases of the ADM:
  • Phase A (Architecture Vision): Initial high-level candidate ABBs.
  • Phase B (Business Architecture): Business function, service, and capability ABBs.
  • Phase C (Information Systems Architectures): Data entity, logical application component, and application service ABBs.
  • Phase D (Technology Architecture): Logical technology components and infrastructure service ABBs.

What an ABB Specification Includes:

An ABB specification typically documents functional capability requirements, required interfaces, security parameters, performance metrics, data schema requirements, and interoperability standards.

---

Solution Building Blocks (SBBs): Realization of Solution

Solution Building Blocks (SBBs) represent the physical realization of ABBs. They are the concrete components, commercial off-the-shelf (COTS) software packages, custom-developed software modules, cloud infrastructure services, or hardware assets selected to satisfy the requirements defined by one or more ABBs.

Key Characteristics of SBBs:

• Vendor and Product-Specific: Tied to specific commercial products, open-source projects, or custom software releases (e.g., Salesforce Enterprise Edition, Apache Kafka 3.4, AWS Aurora PostgreSQL).
• Implementation-Focused: Define physical deployment configurations, operational boundaries, licensing constraints, and technical build specifications.
• Concrete Assets: Represent real software binaries, hardware units, microservices, or platform services that can be procured, installed, or deployed.
• Phase Origin: SBBs are evaluated, candidate-selected, and finalized primarily in Phase E (Opportunities & Solutions), where candidate solutions are matched against baseline and target ABBs, and subsequently implemented in Phase F and Phase G.

What an SBB Specification Includes:

An SBB specification documents product vendor details, exact software build versions, licensing models, physical deployment architecture, operational SLA capabilities, hardware hosting specifications, and implementation cost metrics.

---

Mappings & Relationships Between ABBs and SBBs

The mapping between abstract specifications (ABBs) and physical realizations (SBBs) is flexible and depends on system architecture granularity:

1-to-1 Mapping:           [ ABB: Relational Database ] ----> [ SBB: PostgreSQL 15 ]

1-to-Many Mapping:        [ ABB: Identity & Access ]   ----> +-- [ SBB: Okta (SSO) ]
                                                            +-- [ SBB: CyberArk (PAM) ]
                                                            +-- [ SBB: PingFederate ]

Many-to-One Mapping:        +-- [ ABB: API Gateway ] ----+  
                          +-- [ ABB: Rate Limiter ] ---+---> [ SBB: Kong Enterprise ]
                          +-- [ ABB: Auth Proxy ] -----+

1. One-to-One (1:1): A single logical ABB maps directly to a single physical SBB.
   • Example: An Enterprise RDBMS ABB is satisfied directly by a PostgreSQL 15 instance.
2. One-to-Many (1:N): A single logical ABB requires multiple specialized SBBs working in tandem to fulfill all specification requirements.
   • Example: An Identity and Access Management ABB requires Okta (for Single Sign-On), CyberArk (for Privileged Access Management), and PingFederate (for external federation).
3. Many-to-One (N:1): A single consolidated commercial software product or platform SBB satisfies multiple discrete ABBs simultaneously.
   • Example: An enterprise installs Kong Enterprise, a single product SBB that simultaneously fulfills three separate ABBs: API Gateway ABB, Rate Limiter ABB, and OAuth Token Validation ABB.

---

Life Cycle of Building Blocks in the Architecture Repository

Building blocks are not static; they evolve through an ongoing lifecycle across ADM iterations and are stored in the enterprise Architecture Repository:

1. Identification: Business requirements drive the identification of candidate ABBs during ADM Phases A–D.
2. Specification: Candidate ABBs are formalized with interfaces and standards in the Architecture Definition Document.
3. Evaluation: In Phase E, architecture teams conduct market analysis and Request for Proposal (RFP) evaluations to identify candidate SBBs that satisfy target ABBs.
4. Selection & Procurement: Candidate SBBs are chosen, procured, and pilot-tested.
5. Deployment: Selected SBBs are implemented (Phase G) and become part of the enterprise's operational baseline architecture.
6. Re-use & Governance: Deployed SBBs and mature ABBs are added to the Architecture Repository's Standards Information Base (SIB) and Re-usable Asset Library for future ADM initiatives.

---

Comparison Summary: ABBs vs SBBs

By maintaining a clear division between ABBs and SBBs, enterprise architects ensure that architectural design remains resilient to vendor changes, flexible across cloud environments, and strictly aligned with business goals.