Solution Building Blocks (SBBs)

5 minutes 5 Questions

Solution Building Blocks (SBBs) are concrete, implementable components within the TOGAF Architecture Content Framework that represent actual technology products, services, or components used to construct enterprise solutions. Unlike Architecture Building Blocks (ABBs), which are abstract logical components, SBBs are tangible, real-world implementations. SBBs form the foundation of solution architecture and are derived from the logical design established by ABBs. Each SBB maps to one or more ABBs, creating a bridge between the abstract architectural vision and physical implementation. SBBs include specific products, such as database management systems, application servers, middleware platforms, cloud services, and enterprise resource planning systems. They also encompass technical services like security modules, integration components, and data management tools. In the context of the Architecture Content Framework, SBBs are crucial for several reasons. First, they provide specificity and detail necessary for implementation teams to understand exactly what technology will be deployed. Second, they enable accurate cost estimation and resource planning, as SBBs have defined pricing, licensing, and support models. Third, they facilitate procurement processes by identifying specific vendors and products. Fourth, they support technology selection decisions by evaluating various SBBs against architectural requirements and organizational constraints. The relationship between ABBs and SBBs is essential; while ABBs answer the question of what logical capabilities are needed, SBBs answer how those capabilities will be achieved through specific products and technologies. Organizations may evaluate multiple SBBs for each ABB, comparing factors like total cost of ownership, vendor stability, integration capabilities, and alignment with existing technology landscapes. Throughout TOGAF's Architecture Development Method, SBBs become increasingly relevant during the Technology Architecture and Implementation phases, where abstract designs transform into concrete, deployable solutions that organizations can actually purchase, install, configure, and operate to deliver business value.

Solution Building Blocks (SBBs) in TOGAF 10 Foundation

Understanding Solution Building Blocks (SBBs)


Solution Building Blocks (SBBs) are a fundamental concept in the TOGAF 10 Architecture Content Framework. They represent the concrete, tangible components and services that will be procured, built, or configured to implement the target architecture.


Why Solution Building Blocks Are Important


SBBs are critical for several reasons:


  • Bridge Between Abstract and Concrete: SBBs translate abstract architectural vision into real, implementable solutions that organizations can purchase or develop.
  • Risk Reduction: By mapping business requirements to specific technologies and products, SBBs help identify gaps and potential issues early in the implementation process.
  • Cost Management: SBBs enable organizations to understand the actual technology investments required, making budgeting more accurate.
  • Implementation Clarity: They provide a clear roadmap for development and procurement teams about what exactly needs to be built or purchased.
  • Vendor Selection: SBBs help identify which vendors, products, and services are needed to realize the architecture.

What Are Solution Building Blocks?


SBBs are the technology and implementation-specific building blocks that form the foundation of the target architecture. They represent:


  • Real Products and Services: Specific software packages, hardware platforms, middleware solutions, and services that will be deployed.
  • Configured Components: Products or services that have been customized or configured to meet specific organizational needs.
  • Custom Developments: Bespoke applications or solutions developed specifically for the organization.
  • Integration Points: The connections and interfaces between different solution components.

Key distinction: While Architecture Building Blocks (ABBs) are abstract and technology-independent representations of architectural components, SBBs are their concrete, technology-specific implementations.


How Solution Building Blocks Work


The Relationship Between ABBs and SBBs:


The journey from abstract to concrete involves a clear transformation:


  1. Start with ABBs: Define abstract architectural building blocks that represent logical functions and services needed in the target architecture.
  2. Identify Mapping: Determine which real-world technologies and products can fulfill each ABB's requirements.
  3. Create SBBs: Document specific solutions, products, and services that will implement each ABB.
  4. Validate Completeness: Ensure all ABBs have corresponding SBBs and no implementation gaps exist.

Example:


  • ABB: Customer Data Management System
  • SBBs that implement it: Salesforce CRM platform + Oracle Database + MuleSoft Integration Platform + Custom Java APIs for legacy system integration

Key Characteristics of SBBs:


  • Specific and Concrete: Named products, versions, and configurations that can be purchased or built.
  • Implementable: Have clear implementation paths, timelines, and resource requirements.
  • Measurable: Can be tested, validated, and verified for compliance with architectural requirements.
  • Versioned: Include specific versions and configurations of products.
  • Integrated: Show how they connect with other solution components.

Creating and Managing SBBs


The Process:


  1. Requirements Analysis: Understand detailed technical and functional requirements from ABBs.
  2. Technology Research: Identify available products, platforms, and services in the market.
  3. Evaluation and Selection: Assess vendors, products, and custom development options against requirements.
  4. Documentation: Create detailed specifications for each SBB including:
    • Product/service name and version
    • Configuration details
    • Integration requirements
    • Dependencies on other SBBs
    • Implementation approach (buy, build, configure)
    • Cost and resource estimates
    • Timeline and milestones
  5. Validation: Ensure SBBs collectively implement all ABBs and address all requirements.
  6. Roadmap Development: Create sequencing and phasing for implementation.

Exam Tips: Answering Questions on Solution Building Blocks


1. Distinguish ABBs from SBBs


  • Remember: ABBs are abstract and technology-independent; SBBs are concrete and technology-specific.
  • Exam tip: If a question asks about abstract logical functions, think ABB. If it mentions specific products or technologies, think SBB.
  • Example answer: "ABBs define what we need; SBBs define with what we'll build it."

2. Understand the Mapping Relationship


  • Key concept: One ABB often maps to multiple SBBs. One SBB might contribute to implementing multiple ABBs.
  • Exam tip: When asked about implementation, discuss how you'd map requirements from ABBs to specific technologies in SBBs.
  • Common question: "How do you ensure complete coverage?" Answer: Validate that every ABB has corresponding SBBs and every requirement is addressed.

3. Focus on Practical Implementation


  • SBBs are about: What you actually buy, build, or configure. Include vendor names, product names, versions, and configurations.
  • Exam tip: Look for questions about vendor selection, procurement decisions, or technology choices—these involve SBBs.
  • Example: Rather than "Database Management System" (ABB), say "Oracle Database 21c with specific schemas and security configurations" (SBB).

4. Recognize SBBs in Architecture Development Method (ADM) Phases


  • Phase E (Opportunities and Solutions): SBBs are primarily identified here.
  • Exam tip: Know which ADM phases involve working with SBBs.
  • Context: SBBs are developed after ABBs and feed into implementation planning.

5. Address Integration and Dependencies


  • Key point: SBBs don't exist in isolation. Questions may ask about how SBBs integrate with each other.
  • Exam tip: Discuss interfaces, APIs, data exchanges, and dependencies between SBBs.
  • Example: How would the CRM SBB (Salesforce) integrate with the ERP SBB (SAP)?

6. Consider Cost, Timeline, and Resources


  • SBBs drive: Budget requirements, implementation schedules, staffing needs, and vendor relationships.
  • Exam tip: When questions ask about project planning or resource allocation, SBB decisions are fundamental.
  • Common question type: "How would you sequence the implementation of SBBs?" Consider dependencies and phasing.

7. Use the Right Terminology


  • Key terms to use in answers:
    • "Solution Building Blocks" (not just "building blocks")
    • "Concrete/specific technologies"
    • "Products and services"
    • "Implementation components"
    • "Vendor solutions"
  • Avoid: Using "architecture" vaguely; always specify whether you're discussing ABBs or SBBs.

8. Scenario-Based Questions


  • Approach: When given a scenario, identify what needs to be built/implemented (SBBs required).
  • Example question: "A company needs to integrate three legacy systems. Which SBBs would you recommend?" Answer with specific integration platforms, middleware, custom APIs, and connectors.
  • Exam tip: Discuss both COTS (Commercial Off-The-Shelf) and custom-built SBBs.

9. Documentation and Artifacts


  • Know what documents contain SBB information:
    • Solution Architecture artifacts
    • Implementation roadmap
    • Technology procurement plans
    • Detailed design specifications
  • Exam tip: Questions may ask which artifacts would contain SBB details. Know which deliverables include SBB information.

10. Validation and Verification


  • Key question: "How do you ensure SBBs meet architectural requirements?"
  • Answer approach: Through verification (SBBs built correctly), validation (SBBs meet requirements), testing, and governance.
  • Exam tip: Discuss traceability—how you'd trace requirements from ABBs through SBBs to implementation.

Common Exam Question Patterns


Pattern 1: Definition Questions


"What are Solution Building Blocks?" Answer with the concrete, technology-specific nature and how they differ from ABBs.


Pattern 2: Application Questions


"How would you identify SBBs for a given architecture?" Walk through requirements analysis, technology research, and mapping from ABBs.


Pattern 3: Relationship Questions


"How do ABBs relate to SBBs?" Explain the hierarchical relationship and transformation from abstract to concrete.


Pattern 4: Implementation Questions


"What SBBs would implement a Customer Management ABB?" Provide specific products, platforms, and services.


Quick Reference Summary


AspectArchitecture Building Blocks (ABBs)Solution Building Blocks (SBBs)
NatureAbstractConcrete
Technology-specificNoYes
ExamplesCustomer Management SystemSalesforce CRM + Oracle Database + Custom APIs
Primary PhaseMultiple phasesPhase E (Opportunities and Solutions)
FocusWhat we needWhat we'll use to build it
Detail LevelLogical functionsProducts, versions, configurations
Procurement RelevanceLowHigh

Final Exam Strategy: When answering SBB questions, always emphasize the concrete, implementable nature of SBBs. Show how they trace back to ABBs and forward to implementation plans. Use specific examples with product names and versions. Demonstrate understanding of the ABB-to-SBB transformation process and discuss practical considerations like vendor selection, integration, and phased implementation.

Test mode:
Start practice test

TOGAF Foundation - Solution Building Blocks (SBBs) Example Questions

Test your knowledge of Solution Building Blocks (SBBs)

Question 1

In TOGAF, what constraint applies when multiple Solution Building Blocks are used to fulfill a single Architecture Building Block?

Correct Answer: Each SBB must still conform to the specification defined by the ABB it addresses

In TOGAF, Architecture Building Blocks define specifications and requirements, while Solution Building Blocks represent actual implementations that fulfill those specifications. When multiple SBBs are used to fulfill a single ABB, each SBB must still conform to the specification defined by that ABB, ensuring that the combined solution meets the architectural requirements.

Requiring the same vendor is not a TOGAF constraint and conflates product sourcing with architecture. Requiring each SBB to map to a separate ABB contradicts the premise that multiple SBBs can fulfill one ABB. Architecture Board validation is a governance activity, not a building block conformance constraint.

The key concept tested is the conformance relationship between ABBs as specifications and SBBs as implementations.

Question 2

A team maintains an architecture repository containing several SBBs for 'email integration.' Over time, new vendor products have emerged, and some existing SBBs reference discontinued software. The team wants to ensure their repository remains useful for future projects. What should the team prioritize when deciding which SBBs to retire and which to retain?

Correct Answer: Assess each SBB's continued conformance to its corresponding ABB specifications and verify product availability

The correct answer is right because in TOGAF, Solution Building Blocks (SBBs) are product-specific implementations of Architecture Building Blocks (ABBs), so maintaining an SBB's relevance requires verifying that it still conforms to the ABB specification it implements and that the underlying product or technology remains available and supported.

The option referencing a technology radar and vendor certification introduces concepts outside core TOGAF building block governance. The option focusing on industry-standard integration patterns and licensing costs conflates architectural conformance with financial considerations not central to SBB lifecycle management. The option emphasizing usage frequency and procurement policies focuses on operational and administrative factors rather than the architectural relationship between SBBs and ABBs.

Key concept tested: the relationship between ABBs and SBBs in the Architecture Repository and SBB lifecycle governance.

Question 3

A team has defined an Architecture Building Block (ABB) for 'secure messaging' that specifies encryption standards, message queuing, and delivery guarantees. They now need to identify corresponding Solution Building Blocks. Three vendors offer messaging products, each partially meeting the ABB specification. The team debates how to proceed. Which approach best reflects TOGAF guidance on selecting SBBs in this situation?

Correct Answer: Assess each vendor product against the ABB specification and select the one that best conforms to the defined requirements

TOGAF guidance states that Solution Building Blocks (SBBs) are selected to conform to the specifications defined by Architecture Building Blocks (ABBs), so evaluating each vendor product against the ABB specification and choosing the best fit is the correct approach.

Combining features from all three vendors into a composite SBB introduces unnecessary complexity and integration risk, which is not standard TOGAF practice. Revising the ABB to match a vendor's capabilities undermines the architecture-driven approach by letting implementation dictate architecture. Splitting one ABB across three separate SBBs fragments accountability and creates integration challenges without clear TOGAF justification.

The key concept tested is the relationship between ABBs and SBBs, specifically that SBBs are selected based on conformance to ABB specifications.

More Solution Building Blocks (SBBs) questions
29 questions (total)
Start 29 question test

Other Architecture Content Framework concepts

Architecture ArtifactsArchitecture Building Blocks (ABBs)Architecture DeliverablesArchitecture RepositoryCatalogs, Matrices, and DiagramsContent Framework OverviewReference Models: TRM and III-RMThe Content MetamodelThe Enterprise Continuum
All Architecture Content Framework questions · TOGAF Foundation practice test