Architecture Building Blocks (ABBs) vs Solution Building Blocks (SBBs)
ABBs define WHAT capability is needed. SBBs define HOW that capability is delivered. You can swap any SBB without changing the ABB — that is the power of building block thinking.
A Building Block is a component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. All building blocks — whether ABB or SBB — share six core characteristics:
- ▸♻️ Reusable — can be used across multiple architectures and projects
- ▸🔄 Replaceable — can be swapped with another BB that fulfils the same interface
- ▸📐 Well-specified — has clear, defined boundaries and published interfaces
- ▸🔗 Combinable — works with other BBs through defined interfaces to form larger solutions
- ▸📦 Assemblable — can itself be composed from smaller building blocks
- ▸✅ Requirement-driven — meets or contributes to one or more architecture requirements
ABBs define WHAT functionality will be implemented. They are technology-agnostic — they describe a required capability without mandating any specific product, vendor, or implementation approach.
- ▸Constituent of the architecture model — describes a single aspect of the overall architecture
- ▸Technology-agnostic and vendor-neutral — the ABB says WHAT, never HOW
- ▸Captures requirements, not solutions — shapes the specification
- ▸Produced during architecture development phases (B, C, D)
- ▸Lives in the Architecture Continuum (the left side of the Enterprise Continuum)
- ▸Example: "Centralised Identity Management with SSO capability across all applications"
SBBs are the actual physical implementations that fulfil one or more ABBs. They are physical or supplier-specific, can be business, application, or technology SBBs, and represent real products, systems, or services.
- ▸Candidate physical solution that satisfies ABB requirements
- ▸Physical or supplier-specific — can be business, application, or technology SBBs
- ▸Can be COTS (Commercial Off-The-Shelf), open source, or custom-built
- ▸Identified during Phase E (Opportunities & Solutions) when mapping ABBs to real solutions
- ▸Lives in the Solutions Continuum (the right side of the Enterprise Continuum)
- ▸Example: "Keycloak 24.0 deployed on Kubernetes with LDAP integration"
Explore how CDIPD's real-world ABBs map to their chosen SBBs. Select an example, then click each SBB to see how it fulfils the ABB:
Identity & Access Management
A capability providing centralised authentication, authorisation, and Single Sign-On across all enterprise applications.
Deployed on Kubernetes at CDIPD — handles Keycloak SSO for DWMS, PayFlask, VSSC.
Cloud-based identity service — alternative SBB that fulfils the same ABB.
Another valid SBB — swap Keycloak for Auth0 and the ABB requirement still holds.
One ABB can be fulfilled by multiple SBBs. You can swap one SBB for another without changing the ABB — this is what makes architectures technology-agnostic and future-proof. The ABB is the contract; the SBB is the implementation choice.
Understanding WHERE in the ADM each block type appears is itself a testable concept:
- ▸Phases B, C, D → ABBs are identified and defined (architecture development)
- ▸Phase E → ABBs are mapped to SBBs (opportunities & solutions)
- ▸Phase F → SBBs are included in the Migration Plan with implementation details
- ▸Phase G → SBBs are governed during implementation (compliance checks)
- ▸Both ABBs and SBBs are stored in the Architecture Repository
- ▸ABBs live in the Architecture Continuum; SBBs live in the Solutions Continuum