Application architecture, ABBs, and SBBs
This is the eighth of 10 Information Systems Architecture modules. It introduces application architecture as a responsibility model and explains the ABB and SBB distinction that keeps enterprise judgement independent of vendor choice. The module covers the complete ABB and SBB lists from C220 Part 4 and the G242 content metamodel.
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 G242 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
Real-world case · 2023
Forty-seven applications documented. Zero enterprise needs described.
A water and wastewater utility started its application-architecture work in late 2023 by listing every platform 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 integration 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 target architecture should differ from the baseline.
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?
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
Application architecture 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 enterprise architecture 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 building block 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.
“Application architecture defines the major kinds of application system necessary to process the data and support the business. It describes the applications that are relevant to the enterprise and the relationships and interactions among them.”
TOGAF Standard, 10th Edition - C220 Part 1, Phase C
TOGAF frames application architecture as a responsibility model: what the enterprise needs, not what it currently has. The current estate is described in the baseline. The target architecture describes the future need.
33.2 ABBs and SBBs: the complete distinction
TOGAF distinguishes two levels of building block. The distinction is practical, not academic.
An architecture building block (ABB) 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 solution building block (SBB) 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 G242 content metamodel and application architecture
The content metamodel (described in G242 and C220 Part 4) 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 data entities? This relationship connects application architecture to information architecture.
- Application Component to Business Function. Which application components support which business functions or capabilities? 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.
“The content metamodel defines the standard relationships between entities in an enterprise architecture, ensuring traceability from business function through application component to data entity and technology service.”
TOGAF Standard, 10th Edition - C220 Part 4 and G242
The metamodel prevents application architecture from floating free of business and information context. It enforces the cross-domain traceability that makes Phase C one coordinated domain rather than two separate exercises.
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 governance 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
- 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.
- 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?
- Populate the metamodel relationships. Which data entities does this ABB interact with? Which capabilities does it support? These relationships anchor the ABB in the broader architecture.
- Only then examine which solution options can satisfy it. This is where the SBB conversation begins, informed by the ABB rather than replacing it.
- 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 architecture definition document should capture both the ABB and the SBB with an explicit rationale for the mapping.
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.
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?
Key takeaways
- 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 G242 content 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
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.
Full guide
Defines the standard relationships between entities in an enterprise architecture, including application-to-data and application-to-business traceability.
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.
Module 33 of 64 · Information Systems Architecture