⏱ 21 min read
I’ve lost count of the architecture reviews I’ve sat through where the real issue wasn’t the technology, the budget, or even governance. It was vocabulary dressed up as architecture. architecture decision records
A familiar pattern. A telecom transformation programme approves a target-state component called Customer Identity Service. The architecture board signs it off. Delivery teams leave the meeting assuming that means the IAM platform is basically chosen. Procurement starts shaping documents around a shortlist. Security arrives later and asks awkward but necessary questions about federation, assurance levels, auditability, and cross-channel consent. Interoperability reviewers want to know whether the service must support eIDAS patterns, partner identity brokering, legacy CRM hooks, and multilingual customer journeys. That is usually the moment everyone realises they never properly separated the logical requirement from the implementable solution.
And then the blame starts circulating.
This is where TOGAF’s distinction between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs) stops being exam material and becomes operationally important. In my experience, especially in EU institutions and heavily regulated telecom environments, teams rarely fail because they have never heard the terms. They fail because the terms get treated as glossary items rather than decision tools.
That sounds minor.
It isn’t.
If you blur ABBs and SBBs, procurement gets distorted, standards traceability weakens, migration planning becomes harder than it needs to be, and vendor lock-in starts creeping in long before anyone says “lock-in” out loud. You also make architecture repositories close to useless, because logical intent and implementation choice get shoved into the same folder under similar names and very different abstraction levels.
So I want to take this the way it usually shows up in practice. Not definitions first. Failures first.
Then the distinction.
Then telecom examples, because telecom exposes these mistakes brutally. High integration density, legacy that refuses to die, channel complexity, identity headaches, event-driven flows, OSS/BSS coupling — it is not a forgiving place to be vague.
And finally, some practical tests for telling whether you are looking at an ABB or an SBB, plus a bit of advice on how to document both without turning either into shelfware.
The mistakes I see repeatedly in architecture reviews
Mistake one: treating ABBs as product selections
This is probably the most common one, and honestly the most irritating because it usually gets defended as “being pragmatic.”
I’ve seen architecture packs that literally say things like:
- ABB: Salesforce CRM
- ABB: Oracle Billing
- ABB: Kafka Cluster
- ABB: Keycloak
- ABB: Azure API Management
No. Those are not ABBs.
They may be products. They may end up as part of an SBB landscape. They may even be perfectly sensible choices. But the moment you label a product as an ABB, you have skipped the architectural step where you explain what capability is actually needed, what constraints matter, and what alternative realisations are still valid.
That shortcut feels efficient in a delivery-heavy programme. Usually it isn’t. It just hides the decision earlier.
The consequence is subtle at first. Requirements traceability starts to thin out. Instead of saying, “we need a customer identity verification capability that supports assisted and digital channels, external federation, fraud signals, and strong audit,” the architecture says, in effect, “we need Product X.” That weakens option comparison, turns governance into product endorsement, and often leaves procurement in an awkward position because the architecture artefact has already tilted the market conversation. EA governance checklist
In public and quasi-public environments, this is even riskier. If you are operating under procurement scrutiny, you genuinely need a clean separation between what the enterprise requires and how a specific solution might realise it.
Mistake two: making ABBs so vague they don’t guide anything
The opposite mistake is just as common.
You get ABB inventories full of names like:
- Integration
- Data
- Security
- Reporting
- Workflow
These are not useful building blocks. They are concerns. Themes. Sometimes architecture domains. But they do not constrain design, and if they do not constrain design, they are not doing much architectural work.
“Security” is not an ABB in any useful sense for a telecom onboarding programme. Customer Authentication Capability might be. Consent Management might be. Privileged Access Monitoring might be. Those are bounded enough to define responsibility, interfaces, controls, and non-functionals.
Likewise, “integration” is too broad to survive contact with delivery. But Event Mediation Service for Order Lifecycle Notifications is something you can reason about. You can attach message expectations to it. You can define delivery guarantees. You can state whether it needs schema governance, replay support, latency thresholds, and partner-facing API mediation.
That’s the line I use in reviews: if the so-called ABB cannot drive a meaningful design decision or standards discussion, it is probably too vague.
Mistake three: using SBBs as if they were deployment diagrams
Another recurring confusion: teams discover SBBs and then decide every runtime object must therefore be an SBB.
Not quite.
A Kubernetes node pool is not automatically an SBB. Nor is every server, namespace, container, topic, function, VM, or environment-specific endpoint. Those things matter, of course. But they are not all solution building blocks in the TOGAF sense. TOGAF training
An SBB should represent an implementable solution component or assembly that realises one or more ABBs. It sits closer to engineering and deployment, yes, but it still carries architectural meaning. It is not just a dump of infrastructure topology.
This matters because I often see diagrams with hundreds of boxes labelled “SBB view” that are really just runtime inventory. Useful for operations, maybe. Not very useful for understanding how architecture intent becomes solution structure.
A configured IAM platform offering federation, MFA orchestration, and token services? That can absolutely be an SBB. A Kafka-based event streaming platform with governed topics, schema registry, retention policy, and integration patterns? Also plausible. But “VM-23 in production west region” is not where the SBB conversation should live.
Mistake four: forcing one ABB to one SBB
This one produces some genuinely bad diagrams.
Teams like neat boxes. They want one logical thing to map to one physical thing. Reality tends not to cooperate.
In telecom especially, one ABB may be realised by several SBBs, and one SBB may support several ABBs. That is normal. It is not a modelling failure.
Take an ABB like Customer Interaction Management. In practice it might be realised by:
- a CRM platform
- an API layer
- a notification service
- a consent component
- a document generation service
- a case management module
That is a many-part realisation.
And a single SBB like an API gateway might contribute to:
- Order Capture
- Consent Management
- Product Eligibility Assessment
- Customer Communication
- Partner Exposure
That is one component supporting multiple logical building blocks.
If your architecture repository or notation pushes one-to-one thinking, people start redrawing the world to satisfy the tool. In my experience, that is always a mistake.
Mistake five: documenting ABBs after the solution is already fixed
This is common in programmes where delivery is moving fast and architecture is trying to catch up.
Someone picks the platform, implementation starts, and then the architects are asked to “create the ABBs” for compliance or governance. At that point the ABBs become reverse-engineered labels attached to decisions that are already made. They are no longer architecture instruments. They are documentation residue.
I’m being blunt because I’ve seen this repeatedly in institutional settings. The handover between enterprise architecture and solution delivery is often where the trouble starts. Enterprise architects define broad target capabilities; solution teams, under delivery pressure, select products and patterns; then someone tries to wrap a TOGAF story around it afterwards. The result looks tidy enough on paper. It isn’t. ArchiMate in TOGAF
In EU-facing work, this undermines more than elegance. It affects transparency. If you cannot show how the architectural need was defined before implementation choice, your governance chain becomes difficult to defend.
So what are ABBs and SBBs, really?
After all those failure modes, the definitions are actually fairly simple.
ABBs in plain language
An Architecture Building Block describes what is needed.
Not in a hand-wavy strategy sense. In a usable architecture sense.
An ABB captures a required capability, function, service, data responsibility, or technology service at a logical level. It should be technology-agnostic enough to preserve choice, but specific enough to constrain design. That second part matters more than people often realise. If it preserves every possible choice, it is too abstract. If it effectively names the product, it is too concrete.
A good ABB usually includes:
- its purpose
- the responsibility boundary
- functional expectations
- interface or service expectations
- information involved
- non-functional requirements
- standards and constraints
- dependencies
- ownership or governance accountability
ABBs can exist across business, data, application, and technology architecture. They are not confined to one layer, and in practice many of the useful ones cut across layers anyway.
SBBs in plain language
A Solution Building Block describes how the need will be realised.
This is where products, configured platforms, custom components, shared services, integration mechanisms, operational choices, and transition dependencies come in. SBBs sit closer to procurement and engineering. They usually carry cost, version, hosting, support model, and implementation sequencing.
An SBB can be a commercial product configured for a specific purpose. It can be an open-source platform deployed with a defined operating model. It can be a shared institutional service. It can also be a composite solution made up of several components.
The key point is that it realises one or more ABBs in a concrete way.
The distinction in one sentence
**ABB = the logical or conceptual building block of the architecture.
SBB = the physical or implementable realisation of that building block.**
And one nuance is worth stressing because teams still trip over it: logical does not mean vague, and physical does not mean hardware.
The table teams actually need
Here’s the comparison I end up sketching on whiteboards more often than I’d like.
The note under that table is the bit that really matters: in mature architecture practice, both are necessary. The issue is not choosing one over the other. It is maintaining traceability between them.
That traceability is where architecture earns its keep.
Telecom example: customer onboarding across channels
Let’s make it concrete.
A telecom operator is launching converged mobile and fixed offers. Customers can onboard through retail stores, call centres, web, and partner channels. The programme has to deal with identity assurance, KYC obligations, consent capture, multilingual interactions, legacy BSS integration, and auditable processing across jurisdictions.
In that kind of environment, the target architecture might contain ABBs such as:
- Customer Identity Verification
- Product Eligibility Assessment
- Order Capture
- Credit Risk Evaluation
- Consent Management
- Customer Communication
- Party Master Data Management
- Order Status Event Distribution
Those are useful ABBs because each one names a stable responsibility.
For each one, the architecture should define more than a title. It should define the core capability, interfaces, business rules, non-functionals, and regulatory or standards constraints.
Take Consent Management. At ABB level, I’d expect to see at least this:
- purpose: capture, store, update, revoke, and expose customer consent status across channels and products
- interfaces: query consent, record consent, revoke consent, publish consent change events
- constraints: GDPR compliance, tamper-evident audit trail, consistent consent semantics across channels, response time suitable for assisted sales
- dependencies: customer master, identity verification, communication preferences, channel applications
That is specific enough to guide design without saying “buy product X.”
Now, what SBBs might realise that onboarding architecture?
Possibly:
- a CRM product configured for assisted sales
- an eIDAS-compatible identity provider integration
- a rules engine for eligibility and credit policy
- a consent repository platform
- an API gateway
- a Kafka-based event streaming platform
- an MDM solution
- a notification service
- a document generation platform
Notice the shape of the list. These are implementation-oriented and recognisably solution-facing.
And now the part teams often get wrong: the mapping is many-to-many.
The ABB Customer Identity Verification might be realised by:
- external identity provider connector
- orchestration service
- audit log service
- fraud screening module
The SBB API Gateway might contribute to:
- Order Capture
- Consent Management
- Customer Communication
Likewise, a Kafka platform is not “the Order Status Event Distribution ABB.” It may be part of the SBB set that realises that ABB, along with event producers, schema governance, consumer access controls, and observability tooling. If you simply write “ABB: Kafka,” you have collapsed the architecture into the technology choice and lost the reason the technology is there.
This is one reason I often use telecom as the anchor domain when explaining the distinction. The architecture is too interconnected to survive simplistic modelling for long. If onboarding spans POS, web, partner API, IAM, CRM, MDM, policy engines, and asynchronous event propagation, you need a clean logical picture or the implementation quickly becomes a collection of local optimisations.
Here’s a simplified mapping sketch.
That diagram is simple, but it makes the point. Do not force elegance where the real world is shared and overlapping.
Where this gets messy in real institutions
In institutional and quasi-public environments, the ABB/SBB distinction gets harder for structural reasons.
Procurement rules often push teams to name products early. Interoperability frameworks require explicit standards mappings. Shared services are owned by someone else. Cross-border identity patterns introduce dependencies nobody fully controls. And architecture artefacts may be produced by multiple suppliers with very different maturity levels.
So you get a predictable tension.
Policy and enterprise architecture want reusable capability definitions. Delivery wants named tools, deadlines, and contractable scope. Both pressures are legitimate. The trouble starts when one side pretends the other side’s concern does not exist.
In my experience, ABBs are often authored by enterprise architects, while SBBs emerge in solution teams or supplier design packs. The misunderstanding starts in the handover. Enterprise architecture says, “here is the target capability model.” Delivery hears, “here is a vague wish list.” Delivery says, “here is the solution design.” Enterprise architecture hears, “you skipped the architecture discipline entirely.” free Sparx EA maturity assessment
Both are sometimes right.
A sharper example: network exposure and API monetisation
Let’s move out of classic customer onboarding and into a domain where people jump to product assumptions even faster.
A telecom operator wants to expose network capabilities to enterprise partners: number verification, location, messaging, QoS on demand. That means external developers, API products, partner onboarding, charging, analytics, compliance, and security all need to work together.
Useful ABBs here might include:
- API Product Catalogue
- Consumer Identity and Access Control
- API Traffic Management
- Partner Billing Mediation
- Developer Onboarding
- Usage Analytics
- Policy Enforcement
- Event Notification
These are good ABBs because they preserve the design space while clearly stating responsibilities and constraints.
Possible SBBs might be:
- an API management platform
- an OAuth/OIDC identity service
- a monetisation engine
- an analytics stack
- a portal frontend
- a partner master data module
- mediation adapters into BSS charging systems
The common wrong move is declaring Apigee, MuleSoft, WSO2, or Azure APIM as the architecture before the architecture has actually been done.
I’m not anti-product. Sometimes the shortlist is obvious. Sometimes organisational standards narrow the field. But if the architecture starts and ends with the product name, critical requirements disappear from view:
- rate limiting model
- partner segregation
- audit logging depth
- monetisation support
- policy portability
- data residency constraints
- support for internal versus external API consumers
- linkage into charging and settlement
That is why ABBs matter. They keep the decision criteria visible when the product conversation gets loud.
Don’t define ABBs by layer alone
Another thing I see often: repositories organised strictly into business, data, application, and technology folders, with ABBs forced into one of them as if that settles the matter.
It doesn’t.
Those layers are useful classification aids. They are not a substitute for architectural thinking.
A telecom ABB like Order Status Event Distribution cuts across process milestones, event data semantics, application service boundaries, messaging patterns, and infrastructure expectations. If you file it only as “application architecture,” you risk losing the process meaning and the data contract. If you file it only as “technology,” you reduce it to middleware.
My advice is simple: define ABBs around stable architectural responsibility, not around the folder structure of your repository tool.
That sounds obvious. It apparently is not.
How to write a good ABB without making it unusable
A usable ABB does not need to be long, but it does need to be disciplined.
At minimum, I want to see:
- name and purpose
- architecture domain and scope
- functional responsibilities
- service or interface expectations
- information handled
- constraints and standards
- key non-functionals
- dependencies
- governance owner
What should stay out?
- product names
- version numbers
- environment-specific deployment details
- implementation shortcuts tied to one team’s current delivery approach
Here is a compact telecom example.
ABB: Consent Management
Purpose: capture, manage, and expose customer consent status across channels and products.
Responsibilities: record consent grant and revocation, maintain consent history, support query by authorised channels and services, publish consent change events.
Interfaces: query consent, record consent, revoke consent, retrieve consent history, publish event.
Constraints: GDPR compliance, immutable audit evidence, channel consistency, support multilingual consent statements, sub-second query response for assisted sales.
Dependencies: customer master, identity verification, communication preferences, customer interaction channels.
That is not academic. It is enough to guide design decisions and enough to challenge a weak solution proposal.
And how to write an SBB so engineers can build with it
The opposite problem is SBBs that read like vendor brochures.
A good SBB should say what it realises and how it will operate in your estate. At minimum:
- realised ABBs
- selected product, platform, or component
- configuration scope
- integration points
- deployment and hosting assumptions
- operational model
- security controls
- cost or licensing implications
- transition dependencies
A telecom-flavoured example:
SBB: Consent Service on CRM-adjacent platform
Realises ABBs: Consent Management, Customer Communication Preference Access.
Uses: configured consent repository, REST API layer, Kafka event publication.
Integrates with: web portal, retail POS, customer care desktop, MDM, analytics platform.
Operational notes: active-active deployment, immutable audit storage, retention aligned to regulation, support team shared with CRM platform operations.
That is useful. Engineers can build from it. Architects can govern it. Procurement can understand the scope. Operations can ask sensible questions.
What it should not be is twenty pages of copied product documentation with your logo on the front.
Mapping ABBs to SBBs during ADM work
You do not need to turn this into a TOGAF theory lesson, but the method does matter.
ABBs typically emerge and mature during architecture definition work: Architecture Vision, then business, data, application, and technology architecture development. SBBs become clearer as you move through Opportunities & Solutions, Migration Planning, and Implementation Governance.
That progression is healthy.
If your repository captures only SBBs late in the cycle, you lose reusable architectural knowledge. Every programme starts from product patterns instead of enterprise need.
If your repository captures only ABBs, delivery teams improvise the real solution structure and governance becomes ceremonial.
The value sits in the relationship.
And then there is the awkward part many articles skip: transition architectures.
The ugly middle ground: transition architectures
Transition states are where ABB/SBB confusion usually gets worse, not better.
Why? Because temporary SBBs may realise future ABBs only partially, and legacy platforms often continue to realise ABBs during phased migration.
A telecom example is easy to picture. The legacy CRM still handles order capture for the call centre. A new digital onboarding stack handles web and partner channels. Both partially realise the same target ABB set during migration. Maybe the new IAM flow is live for digital, while assisted channels still rely on older identity handling. Maybe Kafka is carrying digital order events, while batch interfaces still update downstream fulfilment for legacy channels.
That is normal.
The modelling advice is straightforward and, in practice, rarely followed well:
- show the target ABBs once
- map current SBBs separately
- map transition SBBs separately
- be explicit about coexistence rules and sunset dates
Here’s a very simple view.
What matters is not drawing a pretty picture. It is making temporary overlap explicit so governance, funding, and decommissioning decisions are grounded in reality.
What architecture boards should ask
Architecture boards do not need more definitions. They need better questions.
For ABB quality, I usually ask:
- Is this specific enough to constrain design?
- Are standards and non-functionals defined?
- Is it free from premature product bias?
- Does it have a clear responsibility boundary?
- Would two solution teams interpret it roughly the same way?
For SBB quality:
- Which ABBs does it realise?
- What assumptions does it hard-code?
- Does it create unnecessary lock-in?
- Is the operational model credible?
- Can it support the transition state, not just the target state?
And there are anti-patterns I would reject quickly:
- ABB = platform name
- SBB = every microservice
- reusing the same name for the concept and the product
- documenting ABBs only after implementation decisions are already effectively irreversible
A short contrast case from OSS makes the same point in a different domain.
For fault management, ABBs might be:
- Alarm Ingestion
- Event Correlation
- Incident Triggering
- Topology Context Resolution
- Operator Notification
SBBs might include:
- mediation collectors
- event processing engine
- topology graph or CMDB
- ITSM connector
- NOC dashboard tooling
The lesson there is slightly different. In operational telecom domains, ABBs often need much stronger non-functional definition than business-facing teams expect. Throughput, latency, resilience, observability, and failover behaviour belong in the ABB description too. If you leave them out, the eventual SBB choices will optimise for convenience rather than operational reality.
A practical checklist when you are unsure
When a team is stuck, I use a small set of tests.
Ask yourself:
- Am I describing a need or a chosen realisation?
- Could multiple implementation options satisfy this description?
- Does this artefact guide design or specify implementation?
- If I remove the vendor or product name, does the statement still make sense?
- Am I capturing responsibilities or components?
- Do cost, hosting, configuration, and operations matter to this definition?
A decent rule of thumb is this: if replacing the product leaves the statement intact, you are probably still at ABB level. If the artefact depends on hosting assumptions, versioning, licensing, or operational controls, you are probably in SBB territory.
There is no perfect boundary in every repository. I would not pretend otherwise. Different organisations slice things differently. What matters is consistency and traceability.
That, in practice, is the real discipline.
Conclusion: simple idea, difficult habit
The distinction between ABBs and SBBs is simple. But it is not easy.
It is especially not easy in telecom and institutional environments, where integration density is high, procurement is scrutinised, standards pressure is constant, and legacy estates stay alive long after target architectures have been approved in PowerPoint.
Still, the distinction matters.
ABBs define architectural intention. SBBs define implementation realisation. If you collapse them together, you lose optionality too early and clarity too late. If you separate them but never map them, you produce theory on one side and improvisation on the other.
My view, after years of watching this go wrong in programmes that should have known better, is fairly blunt: if your architecture artefacts cannot show how an abstract building block becomes a governed implementation choice, you do not really have an architecture method. You have documentation fragments.
That is why I’d encourage architects to do one thing beyond writing definitions in a glossary.
Model the relationship explicitly.
Show which ABBs exist, why they exist, what constrains them, and how SBBs realise them across current, transition, and target states. Do that consistently and your repository becomes useful. Skip it and the same confusion will return at procurement, at security review, at integration testing, and again during the next transformation wave.
Which, in telecom, usually arrives before the previous one has even finished.
Frequently Asked Questions
What is TOGAF used for?
TOGAF provides a structured approach to developing, governing, and managing enterprise architecture. Its ADM guides architects through phases from vision through business, information systems, and technology architecture to migration planning and governance.
What is the difference between TOGAF and ArchiMate?
TOGAF is a process framework defining how to develop and govern architecture. ArchiMate is a modelling language defining how to represent architecture. They work together: TOGAF provides the method, ArchiMate provides the notation.
Is TOGAF certification worth it?
Yes — TOGAF Foundation and Practitioner are widely recognised, especially in consulting, financial services, and government. Combined with ArchiMate and Sparx EA skills, it significantly strengthens an enterprise architect's profile.