TL;DR
A building block in TOGAF is a reusable package of functionality that can be combined with other building blocks to deliver architectures and solutions. TOGAF distinguishes between Architecture Building Blocks (ABBs) — logical, vendor-neutral — and Solution Building Blocks (SBBs) — concrete, product-specific. ABBs define what is needed; SBBs define how it is implemented.
What is a building block?
A building block is a package of functionality defined to meet business needs across an organization.
Key characteristics:
- recognisable as a distinct component by domain experts
- has a type that corresponds to the enterprise metamodel (e.g. actor, business service, application, data entity)
- can be defined at various levels of detail depending on the architecture stage
- at an early stage, may be just a name or outline description
- later, may be decomposed into supporting building blocks with a full specification
Note
There is no universal set of building blocks. Each organisation decides what arrangement works best for its context.
Qualities of a good building block
A well-designed building block should be:
| Quality | What it means |
|---|---|
| Reusable | Can be applied in multiple contexts across the enterprise |
| Replaceable | Can be swapped out without redesigning the entire architecture |
| Well-specified | Has a clear, documented specification |
| Composable | Can be assembled from other building blocks, or be a sub-assembly of larger ones |
| Interoperable | Works with other building blocks through published, stable interfaces |
| Loosely coupled | Boundaries and specification are defined independently from implementation |
| Implementation-aware | Considers practical usage and evolves to exploit technology and standards |
ABBs vs SBBs
TOGAF distinguishes between two types of building blocks:
| Type | Full name | What it defines | Technology stance | When defined |
|---|---|---|---|---|
| ABB | Architecture Building Block | What capability is needed — abstract, logical | Vendor and technology neutral | Primarily during architecture definition (ADM Phases B–D, with early candidates in Phase A) |
| SBB | Solution Building Block | How that capability is delivered — concrete, product-specific | Vendor and technology aware | Refined in later ADM work (typically Phases D–F) as implementation options are selected |
The relationship
ABBs shape the specification of SBBs. Every SBB should be traceable back to one or more ABBs.
flowchart LR ABB["Architecture Building Block<br/>(what is needed)"] SBB["Solution Building Block<br/>(how it is implemented)"] ABB -->|"guides and constrains"| SBB SBB -.->|"implements"| ABB
Practical example: Video Conferencing
ABB: Video Conferencing Service
An architecture building block that describes the required capability:
- ability for individuals or groups to communicate and collaborate in real time
- audio and video over the internet
- no vendor or product specified — just the functional requirement
SBB: Specific Implementation
A solution building block that implements the ABB:
- specific product selected: e.g. Microsoft Teams, Zoom, or Cisco WebEx
- includes required servers, network design, security configuration, and licensing
- deployment model and integration with existing collaboration tools defined
Building blocks across abstraction levels
Building blocks can exist at different abstraction levels:
| Abstraction level | Building block character | Example |
|---|---|---|
| Conceptual | High-level capability description | ”Customer Identity Management” |
| Logical | Structured, implementation-independent component | ”Identity service with SSO, MFA, and directory sync interfaces” |
| Physical | Concrete product/platform | ”Azure Active Directory with SAML federation to on-prem AD” |
ABBs typically live at the Conceptual and Logical levels. SBBs live at the Physical level.
Building blocks and the Architecture Repository
Building blocks are stored in the Architecture Repository as reusable assets. As the architecture matures through ADM cycles, building blocks are refined, decomposed, and versioned within the repository.
This supports governance, traceability, and reuse across projects and programs.
Exam note
- A building block is a reusable package of functionality defined to meet business needs.
- ABBs are logical, vendor-neutral, and describe what is needed. They are defined primarily in architecture definition work.
- SBBs are concrete, vendor/product-specific, and describe how capability is delivered. They are refined in later ADM work as implementation options are selected.
- ABBs guide and constrain SBBs. Every SBB should trace to one or more ABBs.
- Good building blocks are: reusable, replaceable, well-specified, composable, interoperable, and loosely coupled.
- There is no universal set of building blocks — each organisation defines its own.
- Building blocks can exist at different abstraction levels (conceptual, logical, physical).