TOGAF Architecture Building Blocks vs Solution Building Blocks: What’s the Difference?

The ABB/SBB distinction sounds academic until you hit the governance problem it solves. In TOGAF, an Architecture Building Block (ABB) defines a capability requirement — what the architecture needs — without naming a vendor or product. A Solution Building Block (SBB) is the approved implementation: the specific product or service that provides that capability. ABBs are vendor-agnostic; SBBs are vendor-specific. The mapping between them is your architecture standards register.

Why the distinction matters

Without it, every project team makes independent technology choices. A team implementing "message broker" capability picks RabbitMQ. Another picks Kafka. A third picks Azure Service Bus. A fourth picks AWS SQS. Six months later your integration landscape has four message broker implementations, none of them integrated, all of them needing separate operational expertise.

With the distinction, the ABB "Message Broker" defines what is needed — reliable asynchronous message delivery between applications. The ARB approves one or two SBBs that fulfill it: "Azure Service Bus (approved SBB-MB-01) for cloud-native integration; Apache Kafka (approved SBB-MB-02) for high-throughput event streaming." Every project team selects from the approved SBBs. Sprawl is contained, operational expertise accumulates, and costs come down. The ABB is the standard; the SBB is the approved implementation of that standard.

The two side by side

The cleanest way to hold the difference in mind is to compare what each one carries.

Architecture Building Blocks in Sparx EA

ABBs are modeled as ArchiMate elements at the appropriate layer, with no technology assignment and explicit capability-level documentation.

1. Create an element at the appropriate ArchiMate layer. For an application-layer capability such as "Identity and Access Management," use an Application Component element. For a technology-layer capability such as "Container Orchestration Platform," use a Node element.
2. Apply an «ABB» stereotype. Define this in your project MDG Technology (or use the TOGAF MDG if installed). The stereotype visually distinguishes ABBs from instantiated components in diagrams.
3. Add tagged values to every ABB: abb_id (a unique identifier such as ABB-IAM-001), capability_area, status (Draft / Approved / Deprecated), approved_by (ARB reference and date), rationale (why this capability is needed), and qualifying_criteria (what an SBB must demonstrate to fulfill it).
4. Place all ABBs in a dedicated Architecture Building Block Library package under your governance root. This is the reference every project architect consults when making technology choices.

What an ABB does not contain: vendor names, product names, version numbers, pricing, implementation details. Those belong in SBBs.

Solution Building Blocks in Sparx EA

SBBs are vendor-specific. They reference real products, approved versions, and confirmed costs.

1. Create an element at the same ArchiMate layer as the ABB it fulfills. For an Identity and Access Management ABB, the SBB might be an Application Component named "Microsoft Entra ID" or "Okta."
2. Apply an «SBB» stereotype.
3. Add tagged values: sbb_id, fulfils_abb (reference to the ABB ID this SBB implements), vendor, product, approved_versions, status, approved_by, procurement_path, and annual_cost.
4. Create a Realization relationship from the SBB to the ABB it fulfills. This is the core traceability link — it makes the mapping visible in diagrams and queryable in model reports.
5. Place all SBBs in a dedicated Solution Building Block Library package under your governance root, sibling to the ABB library.

The ABB-to-SBB mapping: your most important governance artifact

The ABB-to-SBB mapping is the architecture standards register. It shows, for every approved capability in the technology estate, which products are authorized to fulfill it.

In Sparx EA, generate this as a Relationship Matrix: ABBs on one axis, SBBs on the other, with Realization relationships shown as matrix cells. The result is a standards matrix you can export and publish for project teams.

This matrix is also the primary input to ARB review of proposed project architectures. When a team proposes a technology choice, the ARB checks: does it exist as an approved SBB? If yes, no review is needed — it is already approved. If no, a formal review is triggered to either approve a new SBB or steer the team to an existing one. This is governance by design: the library does the filtering before the meeting, so ARB sessions become faster and focus on genuinely novel proposals rather than relitigating settled decisions.

Pattern reuse: the strategic value of the library

The strategic value of the building block library is not just governance — it is reuse.

When a project architect starts a new initiative, the first design step should be: "which ABBs does this initiative require, and which approved SBBs will fulfill each one?" If the library is complete, the technology architecture of a typical internal project is 70–80% resolved before any design work begins. The architect's job shifts from technology selection — vendor evaluation, procurement, ARB review — to architecture configuration: assembling approved building blocks into a fit-for-purpose design.

This structure is also what lets AI tools assist with architecture work. When a tool that can query the Sparx EA repository is in place, it can answer questions like "What SBBs are approved for the API management capability?", "Which projects have proposed technology choices not in the SBB library?", or "What is the cost of all approved SBBs across the integration domain?" Those queries only work when the ABB and SBB libraries are structured, tagged, and maintained — an informal standards list in a SharePoint document cannot be queried; a structured Sparx EA library can.

Common building block mistakes

Treating SBBs as permanent. SBBs have lifecycles — products are deprecated, vendors are acquired, better options emerge. Add a review_date tagged value to every SBB and schedule annual ARB reviews. SBBs with status Deprecated should be removed from project option lists immediately.

Creating ABBs that are too granular. An ABB for "PostgreSQL database" is not an ABB — it is an SBB written without a vendor name. ABBs define capability, not technology. "Relational Database Management System" is an ABB; "PostgreSQL (approved for non-critical workloads)" is an SBB.

Not linking ABBs to the architecture layers. An "API Gateway" ABB sits at the technology layer; a "Customer Master Data" ABB sits at the data layer. Keep the layers clear — a mixed-layer library is hard to use and harder to govern.

Maintaining the library in a document. A Word document or SharePoint list cannot generate reports, cannot be queried, and cannot stay in sync with the rest of the architecture model. The building block library belongs in Sparx EA.

Frequently asked questions

Where Sparx Services fits

If your organization's technology standards live in documents rather than a queryable Sparx EA building block library, Configure the Solution is where you fix that — the ABB/SBB library structure, the MDG Technology configuration, and the ARB governance process that make the library a living asset rather than a filing exercise. It is one of the moves we use to take architecture leaders from paralysis to a plan.