Why ABB and SBB Matter in SAP Projects
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.”
Defining ABB and SBB
What Is an Architecture Building Block (ABB)?
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.
What Is a Solution Building Block (SBB)?
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 Purpose of Separating ABB and SBB
Avoiding the “What vs How” Mix-up
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.
Strengthening Governance and Stakeholder Alignment
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.
What to Include in ABBs and SBBs
Typical Contents of an ABB
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:
- Capability purpose and business outcomes.
- Offered services and key business rules.
- Information objects and master data involved.
- Related organizations and roles.
- Constraints, standards, and non‑functional requirements.
- Relationships with other ABBs.
In SAP implementation projects, examples of ABBs are:
- Order Management ABB: covers order entry, delivery date commitment, pricing, shipping coordination, and billing handoff.
- Material and BOM Management ABB: covers product master, BOM, change control, and site rollout rules.
- Production Planning ABB: covers demand planning integration, MRP, capacity checking, and order generation.
- Integration Platform ABB: covers services to connect PLM, MES, WMS, EDI, and ERP.
These ABBs are valuable because they remain valid without naming any product, making them reusable design assets that withstand future technology changes.
Typical Contents of an SBB
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:
- Selected products and components.
- Configuration guidelines and parameterization.
- Interfaces, data flows, and mappings.
- Implementation units and migration waves.
- Operational responsibilities and support boundaries.
- Custom development and enhancement scope.
SAP‑specific examples include:
- Order Management SBB: S/4HANA Sales, Fiori order apps, shipping interface, and billing configuration.
- Material and BOM Management SBB: S/4HANA material master and BOMs, routing, and PLM integration.
- Production Planning SBB: S/4HANA PP/MRP, production orders, capacity planning, and IBP integration.
- Integration Platform SBB: SAP Integration Suite, EDI mappings, API management, monitoring, and retry controls.
While SBBs are vendor‑dependent, they directly underpin feasibility and budgeting; for project managers, SBBs become units of procurement, build, migration, and testing.
ABB and SBB Across ADM Phases
Mapping ADM to SAP Implementation Decisions
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:
- Phase A: Establish high‑level ABBs in the Architecture Vision and define what capabilities the SAP program is intended to strengthen.
- Phase B: Define and refine business ABBs such as O2C, P2P, and Plan‑to‑Produce.
- Phase C: Define data and application ABBs, clarifying master data responsibilities and application services.
- Phase D: Define technology ABBs for integration, security, availability, and platform standards.
- Phase E: Materialize ABBs into concrete SBBs, choosing SAP standard functions, peripheral products, extensions, and deployment options.
- Phase F and beyond: Use SBBs as units for migration planning, rollout waves, and cutover.
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.
Key Differences Between ABB and SBB
Logical vs Physical, Vendor-Neutral vs Vendor-Specific
From TOGAF’s perspective, ABBs and SBBs differ across several dimensions:
- Essence
- ABB: Logical definitions of required capabilities and services.
- SBB: Concrete products, configurations, and development elements that realize those capabilities.
- Level of abstraction
- ABB: High‑level, conceptual, and implementation‑agnostic.
- SBB: Low‑level, detailed, and implementation‑specific.
- Dependency
- ABB: Vendor‑neutral.
- SBB: Vendor‑specific and product‑dependent.
- ADM phases
- ABB: Mainly formed in Phases A–D.
- SBB: Mainly concretized from Phase E onward.
- Management intent
- ABB: Structuring, standardizing, and reusing requirements and capabilities.
- SBB: Operationalizing procurement, build, migration, and support.
- Typical deliverables
- ABB: Capability definitions, service catalogues, logical architecture diagrams.
- SBB: product configuration diagrams, implementation designs, interface specifications, rollout plans.
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.
Practical Use of ABB and SBB in SAP Projects
1. Capability-Based Fit-to-Standard Workshops
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.
2. Structuring Global SAP Templates
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.
3. Clarifying Responsibilities Between SAP and Peripheral Systems
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.
4. Controlling Custom Development and Clean Core
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.
Real-World Examples of ABB/SBB Usage
Example 1 – Order-to-Cash Design
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.
Example 2 – Material, BOM, and Engineering Change Governance
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.
Example 3 – Building a Migration Roadmap
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.
Implications for Project Managers and Enterprise Architects
What Project Managers Gain from ABB/SBB
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.
What Enterprise Architects Gain from ABB/SBB
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?
Summary
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:
- Define what business capabilities the enterprise wants to realize (ABBs).
- Design how SAP and peripheral solutions will implement those capabilities (SBBs).
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.
Reference Links
- TOGAF Building Blocks Overview: http://www.opengroup.org/public/arch/p4/bbs/bbs_intro.htm
- Building Blocks in the TOGAF ADM: https://www.opengroup.org/architecture/0210can/togaf8/doc-review/togaf8cr/c/p4/bbs/bbs_adm.htm
Disclaimer
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.
Leave a Reply