Architecture Building Blocks (ABBs) vs Solution Building Blocks (SBBs)

Enterprise Architecture (EA) often suffers from jargon. Among the most confusing pairs of terms are Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs). They sound similar, but they serve very different purposes in the TOGAF® framework and in everyday architecture work.

This guide shows how ABBs and SBBs fit together, turning abstract ideas into concrete, deployable solutions.

Architecture Building Blocks (ABBs): the reusable ideas

Think of an architectural blueprint. Every wall, every room, every appliance is precisely defined: the kitchen’s layout, the oven’s capacity, the refrigerator’s location. Yet at this stage, nothing is built. That’s exactly what Architecture Building Blocks (ABBs) are: structured, reusable logical elements that describe what the enterprise needs, without specifying how to build it.

In the TOGAF framework, ABBs define the logical structure of the architecture, independent of any specific technology or vendor. They capture business requirements, standards, and capabilities, as well as the relationships between different domains.
An ABB might, for example, express the need to manage customer identities, organise product data, or provide a real-time event platform.

These conceptual building blocks exist across all layers of enterprise architecture. At the business layer, they represent processes, roles, or policies. In the data layer, they describe entities, flows, and governance principles. In the application and technology layers, they formalise logical components, interfaces, infrastructure services, and integration standards. Even security has its own ABBs: identity management, controls, compliance, monitoring.

They may be abstract, but they are never vague. Each ABB has a clear purpose, defined inputs and outputs, known dependencies, and non-functional requirements such as performance, interoperability, and resilience. Together, they form the conceptual foundation of the enterprisen, a design language that structures the architecture before any technical decision is made.

Solution Building Blocks (SBBs): the concrete implementations

If ABBs are the blueprint of a house, Solution Building Blocks (SBBs) are the actual building, made of bricks, concrete, and real equipment. They turn architectural intent into reality.

ABBs define what needs to be built; SBBs deliver how it is built. They are tangible components rooted in products and technologies, showing how a logical need is implemented in practice.
If an ABB defines the need for an event platform, the SBB might specify Kafka on Confluent Cloud. If an ABB outlines a requirement for authentication and access, the SBB could be Azure AD B2C configured with multi-factor authentication and automatic provisioning.

SBBs are concrete and operational. They can take the form of business software (Salesforce, SAP, Snowflake), infrastructure services (Kubernetes, Azure Functions, AWS S3), integration and security tools (MuleSoft, Okta, Apigee), or even custom-developed applications. Each has its own interfaces, operational policies, and service levels.
In short, an SBB is the physical realisation of a logical design.

From ABB to SBB: connecting the dots

ABBs and SBBs are not competing notions but two parts of the same process. The first defines the architecture intent, while the second delivers the solution reality.

In practice, an architecture process begins with the design of ABBs, the “what”: the capabilities, information flows, and architectural patterns that describe the enterprise at a conceptual level. From there, architects derive or select SBBs, the “how”: the concrete technologies that realise those requirements within real-world constraints such as budget, compliance, or available skills.

From Intent to Implementation

This connection is fundamental. The ABB “Customer Relationship Management” may be realised through the SBB Salesforce CRM. The ABB “Event Streaming Backbone” might correspond to Apache Kafka or AWS Kinesis. The ABB “Operational Data Store” could translate into Snowflake in one context or PostgreSQL in another. Maintaining this mapping ensures that every system deployed in production aligns with a defined architectural intent, rather than emerging from ad-hoc project decisions.

In essence, ABBs express strategy while SBBs deliver execution. The relationship between the two is what makes architecture actionable and traceable across the enterprise.

This mapping is the bridge between strategy and execution.
It ensures that every product deployed in production serves a defined architectural intent, not just a local project need.

Why the distinction matters

Failing to distinguish ABBs and SBBs is a common source of confusion. When organisations rush to define SBBs before articulating their ABBs, they risk locking themselves into vendors before understanding their true needs. When they remain at the ABB level without translating their ideas into SBBs, they end up with elegant models that never materialise. And when they lose the connection between the two, they break governance: no one can trace how business intent becomes operational reality.

A balanced approach ensures that ABBs provide reusability and coherence across the enterprise, while SBBs ensure concrete delivery and accountability. Together, they make architecture traceable, rational, and adaptive.

As TOGAF 10 summarises it, ABBs direct and guide the development of SBBs, and every SBB should be traceable to one or more ABBs. This traceability is the foundation of architectural transparency.

To avoid confusion and maintain alignment, architects should:

1. Define ABBs first, to clarify intent and standardise vocabulary.
2. Select SBBs that realise those ABBs within the enterprise’s constraints.
3. Keep both views visible and linked inside a shared repository.

The architect’s craft: keeping abstraction and reality in sync

A mature architecture practice maintains both perspectives simultaneously.

At design time, architects define ABBs: the shared language of capabilities, standards, and interfaces. At delivery time, teams implement SBBs: the technologies, configurations, and integrations that realise those capabilities.

Over time, these mappings evolve. New technologies appear, older ones retire, but the underlying ABBs often remain stable. This is why leading organisations invest in an Architecture Repository, a living catalogue where ABBs and SBBs coexist, linked through traceability rules and visual relationships.

How Boldo modernises Enterprise Architecture

Traditional enterprise architecture tools often make it difficult to see how strategy connects to implementation. Boldo simplifies this. The platform lets architects model ABBs and SBBs as linked, living elements, showing in one view how business capabilities are realised by concrete solutions.

This clarity helps teams move faster from design to delivery and keeps architecture aligned with reality. With Boldo, the ABB-SBB relationship becomes visible, actionable, and easy to maintain.

Conclusion

Enterprise Architecture is the blueprint of the modern organisation. Far from being outdated, it has become a collaborative, data-driven, and outcome-oriented discipline. By combining structured frameworks like TOGAF with modern, visual platforms such as Boldo, organisations gain clarity, resilience, and agility.

In a world where technology changes faster than strategy, maintaining the link between ABBs and SBBs ensures that every system serves a purpose and every investment aligns with the bigger picture. Architecture then becomes what it was always meant to be: the art of connecting ideas and reality.

FAQ