8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition

8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition

A central tenet of the TOGAF Standard is the fundamental distinction between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs). Understanding the relationship, lifecycle, and transition mechanics between these two constructs is essential for passing the TOGAF Enterprise Architecture Practitioner examination.

During Phases A through D, enterprise architects operate primarily in the realm of ABBs, defining logical, vendor-neutral specifications of what the enterprise requires. In Phase E (Opportunities and Solutions), architects pivot to evaluate and identify candidate SBBs—the physical, procured, or engineered components that will realize those specifications.

---

The Building Block Paradigm in TOGAF

A Building Block in the TOGAF Standard is a package of functionality defined to meet the business needs across an organization. Building blocks are designed to be reusable and replaceable. They have standardized interfaces, well-defined boundaries, and can be combined with other building blocks to deliver complex business and technical capabilities.

The TOGAF Architecture Development Method (ADM) deliberately separates building blocks into two tiers of abstraction:

1. Architecture Building Blocks (ABBs): Capture the architecture requirements (the "What").
2. Solution Building Blocks (SBBs): Capture the solution realization (the "How").

---

Architecture Building Blocks (ABBs): The "What"

ABBs are developed, refined, and documented during the architecture definition phases: Phase A (Architecture Vision), Phase B (Business Architecture), Phase C (Information Systems Architectures), and Phase D (Technology Architecture).

Core Characteristics of ABBs:

• Vendor and Product Neutral: An ABB must never specify a proprietary brand, commercial software vendor, or specific product version. For example, an ABB is specified as an "Enterprise Identity and Access Management Service" or an "Event Streaming Broker", never as "Okta" or "Apache Kafka".
• Captures Architecture Requirements: Defines what functionality is required, which business capabilities are enabled, and which data entities are consumed or produced.
• Defines Interoperability and Interfaces: Specifies the logical interfaces, standard protocols (e.g., RESTful JSON over HTTPS, gRPC, OAuth 2.0/OIDC), and data interchange formats required for cross-system integration.
• Specifies Non-Functional Requirements (NFRs): Establishes explicit architectural constraints, including availability targets (e.g., 99.99% uptime), latency thresholds (e.g., sub-50ms response time at p99), throughput capacity, disaster recovery objectives (RTO < 15 minutes, RPO = 0), and security classification levels.
• Guides Solution Procurement: Serves as the authoritative architectural blueprint against which candidate products and implementation technologies are evaluated.

---

Solution Building Blocks (SBBs): The "How"

SBBs represent the concrete, physical realization of ABBs. They are identified as candidate SBBs in Phase E (Opportunities and Solutions), negotiated and incorporated into project plans in Phase F (Migration Planning), and deployed, customized, or engineered in Phase G (Implementation Governance).

Core Characteristics of SBBs:

• Product and Vendor Specific: An SBB represents a physical, procured, or developed component. Examples include "Salesforce Service Cloud Enterprise Edition", "Amazon Aurora Serverless PostgreSQL", "Red Hat OpenShift Container Platform v4.14", or a custom-coded Python microservice implementing proprietary underwriting algorithms.
• Realizes One or More ABBs: An SBB fulfills the functional requirements, interfaces, and non-functional constraints specified by its governing ABBs.
• Contains Physical Implementation Details: Documents the software licenses, hardware specifications, deployment topologies, configuration parameters, and custom code modules required to operate the component.
• Subject to Technology Lifecycles: SBBs have finite operational lifecycles governed by vendor release cadences, deprecation schedules, and hardware obsolescence. When an SBB is replaced (e.g., migrating from an on-premises Oracle database SBB to a managed AWS Aurora SBB), the underlying ABB specification often remains unchanged.

---

Deep Comparison: ABBs vs. SBBs

The following matrix contrasts ABBs and SBBs across key architectural dimensions tested on the practitioner exam:

---

Mapping Dynamics: Realizing ABBs through SBBs

The transition from ABBs to SBBs does not always follow a simplistic 1:1 relationship. Enterprise architects must manage four distinct mapping patterns:

1. One-to-One Mapping (Direct Realization)

A single logical ABB is satisfied directly by a single dedicated SBB.

• Example: An Enterprise Identity Provider ABB is realized directly by an Okta Workforce Identity Cloud SBB.
• Architectural Consideration: Simple governance and clear accountability, but may result in proliferation of standalone niche products if not managed.

2. Many-to-One Mapping (The COTS / ERP Suite Pattern)

Multiple discrete ABBs across different functional domains are realized by a single, comprehensive commercial software package.

• Example: A General Ledger ABB, Accounts Payable ABB, Fixed Assets ABB, and Procurement ABB are all realized collectively by a single SAP S/4HANA Cloud SBB.
• Architectural Consideration: Delivers out-of-the-box data integration between modules, but creates massive vendor lock-in and often forces business compromises where individual suite modules are less capable than specialized point solutions.

3. One-to-Many Mapping (The Composite SBB Pattern)

A single complex ABB requires an integrated collection of multiple physical SBBs to satisfy its full functional and non-functional requirements.

• Example: A Global Data Dissemination ABB requires an Apache Kafka SBB (for event streaming), an Amazon S3 SBB (for cold event archiving), and a Kong API Gateway SBB (for REST payload mediation).
• Architectural Consideration: Provides flexibility to assemble best-of-breed components, but introduces integration complexity, distributed failure modes, and higher operational maintenance overhead.

---

Establishing Objective Product and Vendor Selection Criteria

In Phase E, architects translate the requirements captured in ABBs into objective criteria for evaluating candidate SBBs. This evaluation prevents procurement decisions from being hijacked by vendor marketing hype or superficial feature checklists.

Essential Evaluation Criteria Categories:

1. Functional Alignment: Direct coverage of required business capabilities and user journeys modeled in Phase B.
2. Non-Functional Conformance: Demonstrated ability to meet NFRs specified in the ABB—including concurrent user scalability, sub-second latency, 99.99% availability, and automated failover capabilities.
3. Architectural & Interoperability Fit: Support for open standards (OAuth 2.0, OpenAPI 3.0, CloudEvents), standard containerization (OCI-compliant Docker/Kubernetes), and clean API abstraction without requiring proprietary client libraries.
4. Total Cost of Ownership (TCO): Comprehensive financial modeling encompassing initial software licensing, cloud consumption fees, implementation consulting costs, internal staffing and training, ongoing annual maintenance, and projected data egress expenses over a 5-year horizon.
5. Vendor Longevity and Strategic Roadmap: Financial stability of the vendor, market share, active developer community, frequency of security patching, and alignment between the vendor's product roadmap and the enterprise's strategic vision.

---

Managing Vendor Lock-in and the Customization Trap

One of the most dangerous failure modes in solution architecture is the Customization Trap—heavily altering a commercial off-the-shelf (COTS) software package to match the idiosyncratic, legacy processes of the enterprise.

Why the Customization Trap Destroys Architectural Value:

• Upgrades Become Impossible: Customizing core COTS source code or altering underlying database schemas breaks the vendor's standard upgrade scripts. The enterprise becomes permanently trapped on obsolete software versions, exposing the business to security vulnerabilities.
• Runaway Maintenance Costs: Every vendor patch or security update requires expensive regression testing and manual code refactoring.
• Vendor Support Invalidation: Modifying internal vendor code frequently voids the software vendor's Service Level Agreements (SLAs) and enterprise support contracts.

Architectural Decoupling Strategies:

To avoid vendor lock-in while fulfilling unique business needs, architects mandate the following principles in Phase E:

• Adopt Out-of-the-Box (OOTB) Workflows: Where business processes are non-differentiating (e.g., standard billing, expense reimbursement), adapt the business process to conform to standard COTS workflows.
• Extend via APIs and Anti-Corruption Layers (ACL): If custom differentiation is genuinely required, build external microservices or serverless functions that interact with the COTS SBB strictly via public, supported REST or GraphQL APIs.
• Maintain Technology Neutrality in Enterprise Core: Ensure that core business data models (Canonical Data Models) are preserved independently of the proprietary internal schemas of selected SBBs.

---

Exam Practitioner Scenario: Modernizing Healthcare Claims Adjudication

Scenario: Apex Health Insurance is replacing its 25-year-old COBOL claims processing system. In Phase B and C, the architecture team defined the Automated Claims Adjudication Engine ABB with two non-negotiable requirements:

1. Adjudicate standard ambulatory claims in under 200 milliseconds (p95).
2. Integrate with Apex's proprietary fraud detection machine learning models via gRPC interfaces.

In Phase E, the procurement team presents a leading Commercial Health Payer SaaS suite (Candidate SBB). The vendor claims their platform handles all payer functions out of the box. However, architectural evaluation reveals that:

• The SaaS platform's adjudication latency averages 1.2 seconds per claim (violating NFR 1).
• The vendor's proprietary cloud prohibits outbound gRPC streaming to external machine learning models (violating NFR 2).
• The vendor proposes rewriting Apex's proprietary fraud algorithms directly inside their proprietary scripting language at a cost of $3.5 million.

Architectural Decision: The Lead Enterprise Architect intervenes and rejects the monolithic SaaS SBB for the adjudication core. Instead, the architect recommends a hybrid SBB realization:

• Procure the commercial SaaS SBB strictly for standard member portal, enrollment, and provider billing management (non-differentiating ABBs).
• Engineer a high-performance custom microservice SBB running in Go and Kubernetes to realize the Automated Claims Adjudication Engine ABB, directly invoking the fraud models over gRPC and satisfying the sub-200ms latency requirement.
• This maintains architectural integrity, avoids the $3.5M customization trap, and preserves Apex's core competitive advantage in fraud detection.

---

Common Exam Traps & Pitfalls

• Trap 1: Believing ABBs Specify Vendor Products: Any exam option that describes an Architecture Building Block containing commercial product names (e.g., "The team defined an Oracle 19c ABB") is fundamentally incorrect. ABBs must remain vendor-neutral specifications.
• Trap 2: Assuming SBBs Are Only Software Packages: SBBs are not limited to commercial software products. Custom software modules, database instances, hardware servers, networking appliances, cloud infrastructure resources, and even specialized human operational teams represent valid Solution Building Blocks.
• Trap 3: Premature SBB Selection in Early ADM Phases: Choosing a commercial vendor product in Phase A or Phase B before the business and application architecture requirements have been formalized violates TOGAF governance. Candidate SBBs should be identified and systematically evaluated in Phase E against established ABBs.