Diagram illustrating the TOGAF, ABB, SBB, and SAP governance model for enterprise architecture and solution implementation.
In TOGAF® ADM, architecture is viewed as an interconnected set of building blocks designed to achieve concrete business goals, rather than just diagrams. The Open Group defines a building block as a package of functionality created to meet business needs, and emphasizes that proper selection enhances legacy integration, interoperability, and flexibility.
Within this context, Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs) are core concepts that allow architects to move from abstract design to executable implementation plans. In SAP implementation projects—where business requirements, standard functions, templates, extensions, integrations, and migration planning arise in parallel—clear separation of ABBs and SBBs enables teams to distinguish “what to achieve” from “how to achieve it.”
An Architecture Building Block (ABB) is a logical definition of the capabilities required to meet business needs, defined independently of any specific vendor or product. ABBs are closely related to the Architecture Continuum and are produced and refined through the application of ADM phases.
In practice, ABBs function as capability definition artifacts. Typical ABB themes in SAP-centric manufacturing projects include “global material master management,” “order-to-cash business services,” “manufacturing execution integration,” and “authorization control and audit trail.” Because these ABBs do not yet prescribe SAP S/4HANA, SAP BTP, or third‑party solutions, architects can preserve the purity of business requirements while designing the target architecture.
A Solution Building Block (SBB) represents the concrete implementation of those capabilities using specific products, services, configurations, or developments. SBBs are related to the Solutions Continuum and are realized through procurement or custom development.
In SAP implementation terms, SBBs include SAP S/4HANA standard modules, Fiori applications, SAP BTP Integration Suite, MDG, IBP, Ariba, MES integrations, and add‑ons or custom extensions. When architects define tenants, instances, modules, APIs, interfaces, and customization policies, they are operating in the SBB space.
The primary purpose of distinguishing ABBs from SBBs is to avoid mixing “What capability do we need?” with “How will we implement it?”. The Open Group explains that ADM’s main work is to identify ABBs that satisfy business goals, iteratively refine them, and then reach SBBs that can be procured or developed.
As a result, ABBs carry the role of defining required capabilities aligned with business objectives, while SBBs focus on selecting the optimal implementation means. Without this separation, projects quickly converge on questions such as “Can SAP standard do this?” or “Which add‑on should we buy?” and lose alignment with the underlying business capabilities they are supposed to strengthen.
When ABBs are clearly documented first, product selection and extension decisions can be explained through traceable relationships between capability requirements and SBBs. This makes stakeholder alignment easier and elevates architecture governance, because decisions are justified in terms of business capabilities rather than personal preferences for particular tools.
The Open Group states that in Phases B, C, and D, the target architecture is progressively documented as collections of ABBs. Practically, each ABB should include at least the following:
In SAP implementation projects, examples of ABBs are:
These ABBs are valuable because they remain valid without naming any product, making them reusable design assets that withstand future technology changes.
The Open Group explains that in Phase E, building blocks become more implementation‑specific and are formalized as SBBs, whose interfaces constitute detailed architecture specifications. An SBB should cover:
SAP‑specific examples include:
While SBBs are vendor‑dependent, they directly underpin feasibility and budgeting; for project managers, SBBs become units of procurement, build, migration, and testing.
The Open Group notes that building block definitions evolve throughout ADM and are primarily developed in Phases A to D. In business terms for SAP projects, this can be translated as:
The important point is that ABBs are the starting point of discussion, while SBBs are the units of implementation and investment decisions. If a project jumps straight into SBBs, SAP product combinations drive the conversation, and capability gaps or over‑investment become more likely.
From TOGAF’s perspective, ABBs and SBBs differ across several dimensions:
When the boundary between ABB and SBB is unclear, Fit‑to‑Standard discussions, add‑on decisions, peripheral system rationalization, and global template design become highly personal and inconsistent. Making this boundary explicit raises the repeatability and accountability of project decisions.
Fit‑to‑Standard workshops often drift into product‑centric debates. If ABBs are defined first, business stakeholders can articulate “which capabilities are required,” while IT can evaluate “to what extent SAP standard implements those capabilities.”
For example, when someone claims “pricing is complex, so we need custom development,” an architect can first clarify the Pricing ABB: business rules, condition record granularity, approval controls, and customer‑specific exceptions. Only then are SAP standard pricing techniques evaluated as SBBs, and any unmet requirements extracted as extension SBBs, which helps prevent over‑customization.
The Open Group highlights that building block selection improves flexibility and reuse. In SAP rollouts, common business capabilities should be defined as ABBs and mapped to standard SBB sets that form the global template.
For instance, global ABBs like “material classification,” “BOM management,” “purchase approval,” and “costing” can be standardized, while country‑specific legal or business practices are handled as local ABBs. Common SBBs are templatized, and only local SBBs are added, which simplifies template deviation governance and future maintenance.
In manufacturing, blurred boundaries between ERP, PLM, MES, WMS, EDI, BI, and MDM lead to serious rework later. Using ABBs, architects can first divide responsibility at capability level, then allocate SBBs for SAP and other products.
For example, “Product Definition Management ABB” can be assigned mainly to PLM, “Production Order Execution ABB” to MES, and “Costing ABB” to S/4HANA. When SBBs are designed on top of this model, system‑of‑record decisions, data distribution, and required interfaces naturally emerge from the logical architecture.
Because SBBs represent concrete solutions, add‑ons and custom developments can be modeled explicitly as SBBs. This reframes Z‑developments from “we build because users request them” to “exception SBBs created only when ABB requirements cannot be fulfilled by existing SBBs.”
This approach is aligned with clean core strategies, allowing architects to distinguish standard SBBs, side‑by‑side extension SBBs, and in‑app extension SBBs. Project managers can translate these into cost and schedule implications, while enterprise architects can assess extension justification in governance forums.
In a mid‑size manufacturing SAP project, sales wants end‑to‑end improvements from quotation through billing. Architects first define ABBs such as Order Management ABB, ATP Response ABB, Shipping Integration ABB, and Billing ABB, including services, data, and exception rules.
Then, SBBs such as S/4HANA Sales, ATP functionalities, shipping interfaces, billing configuration, and EDI integration are assigned. This makes it clear which requirements are covered by SAP standard, which require additional design, and which integrations are on the critical path.
Poor quality in material masters, BOMs, and engineering change management often destabilizes production planning and costing after ERP go‑live. By defining Material Master Management ABB, BOM Management ABB, and Engineering Change ABB, architects can clarify data ownership, approval rules, and timing for change propagation.
These ABBs are then realized through SBBs: S/4HANA material master and BOM, PLM integration, workflows, and authorization controls. When ABB–SBB mapping is explicit, master data migration is framed as an architecture initiative for governance improvement rather than a mere data‑load task.
The Open Group indicates that in Phase E, SBBs are detailed and connected to implementation plans. Consequently, SBBs can serve as rollout and cutover units.
For example, a roadmap can be organized into SBB groups such as Common Master Data Platform SBB, Finance SBB, Sales SBB, Procurement SBB, Production Planning SBB, and Peripheral Integration SBB. This clarifies dependencies and enables architects to express architecture priorities directly in the migration plan, especially in multi‑plant or multi‑country deployments.
For project managers, ABBs and SBBs align units of scope, cost, risk, and decision‑making. ABBs help structure user requirements into coherent capabilities, avoiding the fragmentation of scope into unconnected tasks. SBBs then clarify which products, configurations, and developments will implement each capability, enabling consistent estimation, procurement, vendor allocation, and test planning.
In Fit/GAP‑heavy SAP programs, being able to state “which ABB this gap belongs to” is critical. It improves the ability to distinguish gaps that affect core capabilities from those that reflect local customs only, and thus elevates the quality of prioritization and investment decisions.
For enterprise architects, ABBs and SBBs form the backbone of traceability between architecture principles and solution implementations. The Open Group notes that building block definitions evolve iteratively with rationales, standards, and service descriptions.
Architects should define, for each ABB, its purpose, principles, standards, constraints, and responsibility boundaries and then be able to explain how each SBB conforms to or intentionally diverges from them. This transforms architecture reviews from purely technical checks into capability‑driven governance sessions.
When new SaaS, add‑ons, BTP extensions, or data‑platform proposals arise, architects can evaluate them consistently by asking: which ABB do they fulfill, how do they overlap or compete with existing SBBs, and how do they affect future standardization?
In many SAP implementation projects, discussions begin with “what SAP can do.” By applying TOGAF’s ABB and SBB concepts, organizations can reverse that order:
This shift in sequence has a profound impact on template quality, clean‑core adherence, extension control, governance, and long‑term agility. For enterprise architects and project managers, ABBs are not just exam terminology; they are the language of capability and principles, while SBBs are the language of budget, products, and project plans.
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Of all the artifacts in TOGAF ADM Phase B, the Business Footprint Diagram is the…
The Environments and Locations Diagram is a formal TOGAF Phase D artifact that answers which…
The most common failure in early Enterprise Architecture work is misreading the business strategy. This…
Manufacturing integration must balance the rapid harmonization of management reporting with the safe migration of…
A TOGAF-based framework for identifying, evaluating, and mitigating SAP implementation risks in Tier 1 automotive…
Learn how Enterprise Architects can apply TOGAF Initial Risk Assessment, mitigation, and Residual Risk Assessment…