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.

In Sparx EA, you model both as ArchiMate elements with stereotypes and structured tagged values, linked by a Realization relationship. That ABB-to-SBB mapping lets the Architecture Review Board make consistent decisions and contains technology sprawl.

For an architect, the building block library is how technology choices get made once and reused. Today the architect keeps the register in documents and answers project teams one question at a time. The AI-augmented way is for the architect to decide the capability taxonomy and the approval criteria, and for AI to build the library in the repository and check project proposals against it. The skill is defining ABBs at the right level of abstraction and writing qualifying criteria clearly, because AI applies the criteria exactly as written.

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 estate 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, implementation details. Those belong in SBBs.

Solution Building Blocks in Sparx EA

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

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, and procurement_path. Cost belongs to your financial management systems, so connect it to the SBB rather than recording a static figure.
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 novel proposals rather than relitigating settled decisions.

Pattern reuse: the strategic value of the library

The strategic value of the building block library covers governance and 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, most of the technology architecture of a typical internal project is resolved before any design work begins. The architect's job shifts from technology selection, vendor evaluation, procurement, and ARB review to architecture configuration: assembling approved building blocks into a fit-for-purpose design.

This structure is also what lets AI assist with architecture work. When AI is connected to the Sparx EA repository, it can answer questions like "What SBBs are approved for the API management capability?" or "Which projects have proposed technology choices not in the SBB library?" 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, and 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 application layer as a Data Object. Keep the layers clear, because 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

What this means for the architect

If your organization's technology standards live in documents rather than a queryable Sparx EA building block library, the move is to define the taxonomy, the qualifying criteria and the review process, then let AI build and maintain the library in the repository. Configure the Solution sets up the environment around it, and the library is one of the moves that takes architecture leaders from paralysis to a plan.