Direct Answer
Architecture Building Blocks (ABBs) define capability requirements — what the architecture needs — without specifying a vendor or technology. Solution Building Blocks (SBBs) are implementations — how a specific product or service provides that capability. ABBs are vendor-agnostic; SBBs are vendor-specific. The ABB-to-SBB mapping is the governance artifact that shows how approved standards are met by real implementations. In Sparx EA, ABBs are ArchiMate elements with no technology assignment (abstract capability nodes); SBBs are ArchiMate elements realised by specific technology components or vendor products. Maintaining a library of approved ABBs and SBBs in your Sparx EA repository is the foundation of architecture governance — it enables the ARB to make consistent decisions, prevents technology sprawl, and gives AI tools the structured inventory they need to check proposed changes against approved standards.
Why the Distinction Matters
The ABB/SBB distinction sounds academic until you hit the governance problem it solves.
Without the distinction: every project team makes independent technology choices. A team implementing “message broker” capability picks RabbitMQ. Another team picks Kafka. A third picks Azure Service Bus. A fourth picks AWS SQS. Six months later your integration landscape has four different message broker implementations, none of them integrated, all of them requiring 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 fulfil that ABB: “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. Technology sprawl is contained. Operational expertise accumulates. Costs reduce.
The ABB is the standard. The SBB is the approved implementation of that standard.
Architecture Building Blocks in Sparx EA
ABBs are modelled in Sparx EA as ArchiMate elements at the appropriate layer, with no technology assignment and explicit capability-level documentation.
How to model an ABB:
- Create an element at the appropriate ArchiMate layer. For a capability that sits at the application layer — say, “Identity and Access Management” — use an Application Component element. For a capability at the technology layer — “Container Orchestration Platform” — use a Node element.
- Apply a
<stereotype. In Sparx EA, define this stereotype in your project MDG Technology (or use the TOGAF MDG if installed). The stereotype visually distinguishes ABBs from instantiated components in diagrams.>
- Add the following tagged values to every ABB element:
– abbid — a unique identifier (e.g., ABB-IAM-001) – capabilityarea — the architecture domain this ABB belongs to – status — Draft / Approved / Deprecated – approvedby — ARB reference and date – rationale — why this capability is needed (link to Phase A driver or Phase B gap) – qualifyingcriteria — what an SBB must demonstrate to fulfil this ABB
- Place all ABBs in a dedicated
Architecture Building Block Librarypackage under your governance root. This library is the reference that 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.
How to model an SBB:
- Create an element at the same ArchiMate layer as the ABB it fulfils. For an Identity and Access Management ABB, the SBB might be an Application Component element named “Microsoft Entra ID” or “Okta.”
- Apply a
<stereotype.>
- Add the following tagged values:
– sbbid — unique identifier (e.g., SBB-IAM-001) – fulfilsabb — reference to the ABB ID this SBB implements (SBB-IAM-001 fulfils ABB-IAM-001) – vendor — vendor name – product — product name – approvedversions — specific versions that are approved for use – status — Draft / Approved / Deprecated – approvedby — ARB reference and date – procurementpath — how to procure this SBB (existing contract, new procurement, cloud marketplace) – annualcost — estimated or actual annual cost
- Create a Realisation relationship from the SBB to the ABB it fulfils. This is the core traceability relationship — it makes the ABB-to-SBB mapping visible in diagrams and queryable in model reports.
- Place all SBBs in a dedicated
Solution Building Block Librarypackage 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 organisation’s technology estate, which products are authorised to fulfil it.
In Sparx EA, generate this as a Relationship Matrix: ABBs on one axis, SBBs on the other, with Realisation relationships shown as matrix cells. The result is a standards matrix that can be exported and published for project teams.
This matrix is also the primary input to ARB review of proposed project architectures. When a project team proposes a technology choice, the ARB checks: does the proposed technology exist as an approved SBB? If yes, no ARB review needed — it is already approved. If no, a formal ARB review is triggered to either approve a new SBB or reject the proposal in favour of an existing SBB.
This is governance by design. The building block library does the filtering before the ARB meeting. ARB meetings become faster and more focused — reviewing genuinely novel proposals rather than relitigating decisions already made.
Pattern Reuse: The Strategic Value of the Building Block 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 fulfil each ABB?” If the building block 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 (which often means vendor evaluation, procurement, and ARB review) to architecture configuration (assembling approved building blocks into a fit-for-purpose design).
This pattern reuse is also what enables AI tools to assist with architecture design. When Kernaro or Copilot Studio queries the Sparx EA repository via Interface B (MCP), it can answer questions like:
- “What SBBs are approved for the API management capability?”
- “Which projects have proposed technology choices that are not in the SBB library?”
- “What is the cost of all approved SBBs across the integration domain?”
These queries work only when the ABB and SBB libraries are structured, tagged, and maintained. An informal technology standards list in a SharePoint document cannot be queried by an AI tool. A structured Sparx EA building block library can.
Common Building Block Mistakes
Mistake 1: 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 of the SBB library. SBBs with status = Deprecated should be removed from project option lists immediately.
Mistake 2: 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.
Mistake 3: Not linking ABBs to the architecture layers. ABBs exist at specific ArchiMate layers. An “API Gateway” ABB is at the technology layer. A “Customer Master Data” ABB is at the data layer. Keep the layers clear — a mixed-layer ABB library is hard to use and harder to govern.
Mistake 4: Maintaining the library in a document. A Word document or SharePoint list cannot generate reports, cannot be queried by AI tools, and cannot be kept in sync with the rest of the architecture model. The building block library belongs in Sparx EA.
Frequently Asked Questions
Q: How many ABBs should an enterprise have? A: A mature enterprise architecture programme typically has 40–80 approved ABBs covering the core capability areas: infrastructure, platform, integration, security, data management, analytics, and application-layer capabilities. More than 100 is usually a sign that ABBs have become too granular. Fewer than 20 is a sign that the library is incomplete and architects are making undocumented decisions.
Q: Can an ABB have multiple approved SBBs? A: Yes, and this is common for capabilities where different deployment contexts justify different solutions. A “Relational Database” ABB might have approved SBBs for PostgreSQL (approved for cloud-native workloads), Microsoft SQL Server (approved for existing on-premises workloads), and Azure SQL Database (approved for Azure-hosted applications). The qualifying criteria on each SBB make the context clear.
Q: How does the building block library relate to the technology standards register? A: They are the same thing, structured differently. The technology standards register is typically a governance document listing approved technologies. The building block library in Sparx EA is the same information as a queryable, diagram-able, AI-accessible model. If your organisation already has a technology standards register, the first step is to migrate it into the Sparx EA building block library structure.
Q: Who owns the building block library? A: The Chief Architect or Architecture Practice Lead owns the library as a whole. Individual ABBs should have domain owners — typically the domain architect for each capability area. The ARB is the approval body for new ABBs and SBBs, and for SBB deprecation decisions. Without clear ownership, the library goes stale within months.
Q: How do we handle open-source SBBs that have no vendor? A: Model the SBB with vendor = Community / Open Source and product = [product name]. Add a support_model tagged value (e.g., “Commercial support via [support vendor]” or “Internal support”). Open-source SBBs need more governance scrutiny, not less — the licence, security posture, and support model need to be documented just as rigorously as commercial SBBs.
Q: Can AI tools query the building block library directly? A: Yes, when EA GraphLink Interface B (MCP) is configured. An AI assistant can answer natural-language questions about the building block library by querying the Sparx EA repository. Example queries: “What is approved for container orchestration?”, “Which SBBs are due for annual review?”, “List all SBBs with status Deprecated that are still referenced by active projects.” This capability is only possible when the library is in Sparx EA with consistent tagged values.
Q: How does the ABB/SBB concept apply to MBSE programmes? A: In MBSE (systems engineering) programmes, ABBs correspond to logical system blocks — capability definitions at the system level. SBBs correspond to physical components or commercial off-the-shelf items that fulfil those logical capabilities. The governance pattern is identical: define what the system needs (ABB/logical block), then select approved implementations (SBB/physical component). SysML BDD in Sparx EA is the natural modeling language for MBSE building blocks.
Q: What is the Amplify engagement’s role in building block governance? A: The Amplify engagement includes building block library design and population as a core deliverable. We work with your architecture team to define the ABB taxonomy, establish the MDG Technology extensions in Sparx EA for ABB and SBB stereotypes and tagged values, populate the initial library from your existing technology standards documentation, and configure the ARB review process for library additions and updates.
Next Step
If your organisation’s technology standards are living in documents rather than a queryable Sparx EA building block library, the Amplify engagement is where you fix that. Amplify delivers the ABB/SBB library structure, the MDG Technology configuration, and the ARB governance process that makes the library a living governance asset rather than a filing exercise.
