Application architecture, ABBs, and SBBs

25 min 6 outcomes 1 interactive tool 3 standards cited

describes the responsibilities the enterprise needs from its software rather than the products that currently provide them, and it draws the and distinction that keeps enterprise judgement independent of vendor choice. The module covers the complete ABB and SBB lists and the , both from the Architecture Content volume of C220.

By the end of this module you will be able to:

  • Explain application architecture as a responsibility model rather than a product list
  • Distinguish architecture building blocks from solution building blocks in practical language
  • List the complete set of ABB and SBB characteristics from C220 Part 4 and explain what each one protects
  • Describe how the TOGAF content metamodel connects application components to data entities, business functions, and technology services
  • Show why naming the ABB first preserves architectural independence
  • Apply ABB and SBB reasoning to the London planning, publication, telemetry, and governance case

Forty-seven applications documented. Zero enterprise needs described.

A water and wastewater utility started its application-architecture work in late 2023 by listing every in the estate and mapping data flows between them. After twelve weeks, the team had a detailed current-state diagram with forty-seven applications and over two hundred lines.

The CIO reviewed the output and asked: "What does this tell us about what we actually need?" The answer was not much. The diagram described the current reality in exhaustive detail, but it said nothing about what application responsibilities the enterprise required, which of those responsibilities were missing or duplicated, or how the should differ from the .

The team had documented products. It had not described the enterprise needs that those products were supposed to serve. That distinction between product-first thinking and responsibility-first thinking is the core of this module.

If an application architecture documents every product in the estate but says nothing about what the enterprise actually needs, has it described the architecture or just the current reality?

From capability to Architecture Building Block to Solution Building Block

An Architecture Building Block says what the business needs in technology-neutral words it can agree to, and a Solution Building Block names the specific product that will deliver it, so getting this split right means the architecture survives when the product choice changes.

From capability to Architecture Building Block to Solution Building Block A three-column trace, one row per GB-energy capability, reading left to right from a Capability through a flow arrow to an Architecture Building Block in a soft accent tint (what is needed, technology-neutral) then to a white Solution Building Block (the named product). Asset data integration becomes a master data platform for network assets, then Databricks Delta Lake on Azure with Apache NiFi ingestion. Customer connections self-service becomes a secure portal for customer-initiated connection requests, then Next.js on Vercel with Auth0 SSO and Postgres. Real-time network monitoring becomes a SCADA platform capable of IEC 61850 substation integration, then GE iFIX with PRV gateways. Capability Architecture Building Block Solution Building Block what the business needs what is needed, technology-neutral the named product chosen 1Asset dataintegrationA master data platformfor network assetsDatabricks Delta Lakeon Azure with ApacheNiFi ingestion 2Customer connectionsself-serviceA secure portal forcustomer-initiatedconnection requestsNext.js on Vercel, withAuth0 SSO and Postgresbackend 3Real-time networkmonitoringA SCADA platform capableof IEC 61850 substationintegrationGE iFIX paired with PRVsubstation gateways Abstract ABB, technology-neutralConcrete SBB, the named product

That story illustrates why application architecture should describe responsibilities before products. When the vendor enters the conversation too early, the enterprise reasoning that should drive the choice gets compressed or skipped entirely.

33.1 Why application architecture starts with responsibility

should describe the logical application responsibilities the enterprise needs and the interactions among them. That is a different task from naming the products that will eventually deliver those responsibilities.

This distinction matters because loses much of its value if the product choice is allowed to define the architecture prematurely. When the vendor enters the conversation too early, the enterprise reasoning that should drive the choice gets compressed or skipped entirely.

TOGAF structures this through the concept. A building block is a reusable component of enterprise capability that can be combined with others to deliver architectures and solutions. The standard distinguishes two levels of building block, and that distinction is the foundation of this module.

33.2 ABBs and SBBs: the complete distinction

TOGAF distinguishes two levels of . The distinction is practical, not academic.

An is a logical description of what the architecture needs, including the role, capability, constraints, and relationships involved. C220 Part 4 specifies that an ABB should have the following characteristics:

  • It captures architecture requirements, including functional and non-functional aspects.
  • It is technology-aware but product-neutral. It may reference a class of technology without naming a specific product.
  • It guides and constrains the subsequent selection of SBBs.
  • It defines the interfaces to other ABBs.
  • It includes a set of architecture specifications, including functional requirements and qualities of service.
  • It is reusable across multiple solution contexts.

A is a concrete implementation component, product, or configured service chosen to realise the architectural need described by the ABB. C220 Part 4 specifies that an SBB should have the following characteristics:

  • It defines the implementation of a specific solution aspect.
  • It is product-specific or technology-specific.
  • It realises the requirements specified by one or more ABBs.
  • It includes specifications for build, buy, or reuse decisions.
  • It defines the detailed interfaces and integration points.
  • It is constrained by the quality of service and interface specifications of the ABBs it realises.

The ABB describes what the enterprise needs. The SBB describes what the enterprise selects to deliver that need. Keeping them separate preserves the ability to compare, govern, and change solution choices against a stable logical requirement.

33.3 The content metamodel and application architecture

The (defined in the Architecture Content volume of C220, which renames it the Enterprise Metamodel in the 10th Edition) defines the standard relationships between the entities that make up an enterprise architecture. For application architecture, the metamodel shows how application components connect to the rest of the architecture.

The key relationships in the application domain are:

  • Application Component to Data Entity. Which application components create, read, update, or delete which ? This relationship connects application architecture to information architecture.
  • Application Component to Business Function. Which application components support which business functions or ? This relationship connects application architecture to business architecture.
  • Application Component to Technology Service. Which technology services host or support which application components? This relationship connects application architecture to technology architecture (Phase D).
  • Application Component to Application Component. Which application components interact with which other application components, and through what interfaces? This relationship maps the application interactions.
  • Logical Application Component to Physical Application Component. How do ABBs (logical) map to SBBs (physical)? This is the traceability link that ensures every product choice can be traced back to an enterprise need.

The metamodel matters because it prevents application architecture from becoming an isolated diagram. When the relationships are populated, the application view is traceable to business needs (through capabilities), to information needs (through data entities), and to technology constraints (through services). That traceability is what makes the architecture governable.

33.4 Why the distinction is worth protecting

Four practical benefits follow from maintaining the ABB and SBB separation.

  • It preserves the ability to compare solution options against a stable logical need.
  • It improves reuse because the enterprise can see shared architectural responsibilities before vendors enter the room.
  • It helps because the rationale for selection is clearer when the logical requirement is already defined.
  • It stops procurement pressure from pretending to be architecture reasoning.

Common misconception

“Naming the vendor platform as the architecture building block is acceptable shorthand.”

Calling a vendor platform the architecture building block usually means the logical architecture layer has already been skipped. If the ABB is named after a product, the enterprise has lost its independent view of what it needs.

33.5 How to use ABB and SBB thinking well

  1. Name the application responsibility in enterprise terms first. "Planning-evidence preparation service" is an enterprise responsibility. "SAP Analytics Cloud" is a product. The ABB uses the first framing.
  2. State the interfaces, information needs, and constraints. What information does this responsibility consume and produce? What authority rules from Module 28 apply? What quality-of-service requirements constrain the design?
  3. Populate the metamodel relationships. Which does this ABB interact with? Which does it support? These relationships anchor the ABB in the broader architecture.
  4. Only then examine which solution options can satisfy it. This is where the SBB conversation begins, informed by the ABB rather than replacing it.
  5. Record why the selected SBB fits the ABB. The selection record should trace back to the enterprise requirement, not forward from the vendor pitch. The should capture both the ABB and the SBB with an explicit rationale for the mapping.

The ABB to SBB selection trace from pattern to delivery

A Solution Building Block never lands without an Architecture Building Block above it to justify it: the architect selects a pattern, the board evaluates it, and only the realised solution, the single step that carries cost and vendor lock-in, is contracted into delivery.

The ABB to SBB selection trace from pattern to delivery A vertical abstraction ladder of four steps with a left-hand axis labelled more concrete and accent flow arrows carrying the trace verbs between steps. From the top: L1 ABB pattern, the abstract capability the architecture needs; an arrow labelled select leads to L2 ABB selected, the named pattern from the catalogue; an arrow labelled evaluate leads to L3 SBB candidate, a vendor product or in-house build under review; an arrow labelled realise leads to L4 SBB realised, chosen, contracted and integrated into delivery, carrying a soft accent tint as the destination the trace reaches. A right-hand bracket groups the top two steps as ABB architecture work and the bottom two as SBB delivery work. More concrete From pattern to delivered solution L1ABB patternAbstract capability the architecture needsArchitect L2ABB selectedNamed pattern chosen from the catalogueArch board L3SBB candidateVendor product or in-house build under reviewArchitect L4SBB realisedChosen, contracted, integrated into deliveryDelivery Select Evaluate Realise ABB work architecture SBB work delivery

London Grid Distribution

In London, application architecture needs to clarify responsibilities for planning evidence, publication preparation, telemetry handling, customer interaction, and governance support before any one platform is privileged.

The London ABB catalogue should include at minimum:

  • Planning-evidence preparation service. Prepares forecasts and scenario outputs for governance and publication use.
  • Publication management service. Governs the preparation, validation, and release of LTDS-style external publications.
  • Telemetry ingestion service. Captures, validates, and distributes real-time operational data from field sensors and SCADA.
  • Customer-data stewardship service. Governs customer identity, matching, and lifecycle across contributing systems.
  • Network-model management service. Maintains the enterprise network topology and connectivity model.
  • Governance reporting service. Produces board-level and regulatory reports from governed analytical products.

Each London ABB should be populated with metamodel relationships showing which data entities it interacts with, which capabilities it supports, and what interfaces connect it to other ABBs. The SBBs (specific platforms) are chosen afterwards, with an explicit record of why each SBB fits the ABB it realises.

Check your understanding

An application architecture lists forty-seven current products and maps data flows between them. A senior architect observes that the architecture does not describe what the enterprise actually needs. What is missing?

C220 Part 4 states that an ABB should be 'technology-aware but product-neutral.' What does this mean in practice?

A procurement team argues that selecting the platform first is more efficient because the vendor can adapt. An architect pushes back. What is the strongest architectural argument?

Loading interactive component...

Core distinctions

  • Application architecture should define responsibilities before products. ABBs describe the logical need; SBBs describe the concrete implementation.
  • C220 Part 4 specifies complete characteristic lists for both ABBs and SBBs. ABBs are technology-aware but product-neutral. SBBs are product-specific and constrained by ABB specifications.
  • The content metamodel, the 10th Edition's Enterprise Metamodel, connects application components to data entities, business functions, and technology services, preventing application architecture from floating free of enterprise context.
  • The ABB-to-SBB mapping should be documented with explicit rationale. Every product choice should trace back to an enterprise need.
  • Vendor choice is stronger when it follows architecture reasoning instead of replacing it.
  • The London ABB catalogue should cover planning evidence, publication management, telemetry, customer stewardship, network model management, and governance reporting.

Standards and sources cited in this module

  1. The TOGAF Standard, 10th Edition (C220)

    Part 4, Architecture Content Framework

    Core standard for building block characteristics, ABB and SBB definitions, and architecture content structures.

  2. The TOGAF Standard, 10th Edition (C220)

    Architecture Content: TOGAF Content Framework and Enterprise Metamodel

    Defines the standard relationships between entities in an enterprise architecture, including application-to-data and application-to-business traceability.

  3. G248, Selecting Building Blocks

    Full guide

    Primary guide for ABB and SBB discipline within the TOGAF ecosystem.

You now understand how ABBs and SBBs keep architecture reasoning independent, and how the content metamodel connects application architecture to the broader enterprise. The next question is: how should integration, interoperability, and coupling decisions be made at enterprise level? That is Module 34.

Back: Business intelligence, analytics, and decision supportNext: Integration, interoperability, and coupling decisions

Module 33 of 72 · Information Systems Architecture