This infographic explains how SAP RBA’s four enterprise domains connect through holistic enterprise architecture.
When implementing SAP S/4HANA globally, many organizations tend to begin by asking questions such as:
“Which SAP solutions should we implement?”
or:
“Which business processes should we standardize?”
From an Enterprise Architecture (EA) perspective, however, there is a more fundamental question that should be addressed first:
“Which areas of the enterprise are we trying to transform through this Business Transformation?”
This is where the concept of Enterprise Domains in SAP Reference Business Architecture (RBA) becomes particularly valuable.
This article explains what Enterprise Domains are, what the four Enterprise Domains represent, how they relate to Business Capabilities and Business Processes, and how they can be applied to a global SAP transformation.
SAP Reference Business Architecture (RBA) provides Reference Architecture content that helps organizations understand and structure their Business Architecture.
One of the most important characteristics of SAP RBA is that its Business Architecture models are solution-agnostic.
Rather than starting with a particular SAP product, RBA allows organizations to first understand the business itself.
Within SAP RBA, two important perspectives are:
The Business Capability Model describes:
“What does the organization need to be able to do?”
to create value, execute its business model, and achieve its strategic objectives.
The Business Process Model describes:
“How does the organization perform its activities to create value and achieve business outcomes?”
At the highest level, both models are anchored by Enterprise Domains.
An Enterprise Domain provides a high-level structure for organizing enterprise activities according to the core functions and value creation of the organization.
SAP Reference Business Architecture uses four Enterprise Domains:
At a high level, the enterprise can therefore be viewed as follows:
Enterprise
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Product & Service Customer Supply
Develop Products Generate Demand Fulfill Demand
& Services
│
│
▼
Corporate
Plan & Manage Enterprise
These Enterprise Domains should not be interpreted as an organizational chart.
They do not represent departments such as Sales, Manufacturing, Finance, or IT.
Instead, they provide an architectural structure for understanding:
“Which areas of business value creation does the enterprise need to perform?”
Because of this distinction, Enterprise Domains can remain relatively stable even when organizational structures change.
Let us examine each Enterprise Domain using an automotive Tier 1 supplier as an example.
This domain covers activities related to planning, designing, developing, and managing products and services.
For an automotive Tier 1 supplier, this may include:
For example, when developing a new component for an electric vehicle, activities may include:
Market Requirements → Product Planning → Product Design → Engineering → Handover to Manufacturing
From an SAP perspective, areas such as Product Lifecycle Management and Engineering may eventually support capabilities within this Enterprise Domain.
However, the Enterprise Domain itself remains independent of a particular SAP solution.
The Customer Enterprise Domain focuses on establishing relationships with markets and customers and generating demand for the organization’s products and services.
For an automotive Tier 1 supplier, relevant activities may include:
A simplified example might be:
OEM RFQ → Quotation → Negotiation → Contract → Customer Order
Unlike many consumer-oriented industries, automotive suppliers often manage long-term relationships with specific OEMs.
Processes such as RFQ management, target costing, quotation, and program management can therefore play an important role within the overall customer-facing architecture.
The Supply Enterprise Domain focuses on fulfilling the demand generated by customers and other parts of the enterprise.
For manufacturing companies, this is often one of the most important Enterprise Domains within an SAP transformation.
Relevant areas may include:
For an automotive Tier 1 supplier, the overall flow might look like this:
OEM Demand
↓
Demand Planning
↓
Supply Planning
↓
Procurement
↓
Production Planning
↓
Manufacturing
↓
Warehouse
↓
Transportation
↓
OEM Delivery
When moving from Business Architecture to Solution Architecture, this domain may eventually involve solutions such as:
Again, these SAP solutions should not be confused with the Enterprise Domain itself.
The Enterprise Domain represents the business perspective; the SAP solutions represent part of the technology architecture used to enable it.
The Corporate Enterprise Domain covers activities required to plan, govern, manage, and support the enterprise as a whole.
Examples include:
For an automotive Tier 1 supplier, this may include managing:
From an SAP solution perspective, this may eventually involve capabilities provided by solutions such as SAP S/4HANA Finance, Group Reporting, Treasury, and SAP SuccessFactors.
This relationship is essential to understanding Enterprise Domains.
Within the SAP RBA Business Capability Model, Business Capabilities are conceptually structured as follows:
Enterprise Domain
│
▼
Business Domain
│
▼
Business Area
│
▼
Business Capability
Consider the Supply Enterprise Domain.
A simplified example might be:
Enterprise Domain
Supply – Fulfill Demand
│
▼
Business Domain
Supply Chain Planning
│
▼
Business Area
Demand Planning
│
▼
Business Capability
Demand Forecasting
Demand Review
…
The Enterprise Domain itself is therefore not a detailed Business Capability.
Instead, it acts as a high-level anchor for determining where Business Domains, Business Areas, and Business Capabilities belong within the overall enterprise architecture.
Enterprise Domains are also important for understanding the Business Process Model.
Within SAP Reference Business Architecture, the Business Process Model is structured through:
Enterprise Domain
│
▼
End-to-End Business Process
│
▼
Business Process Module
│
▼
Business Process Segment
│
▼
Business Activity
For example, within the Supply Enterprise Domain, end-to-end processes such as Plan to Fulfill can be represented.
An important distinction is:
Business Capability = WHAT the organization needs to be able to do
while:
Business Process = HOW the organization creates value and achieves an outcome
Conceptually:
Enterprise Domain
Supply
│
├────────────────┐
▼ ▼
Business Business
Capability Process
WHAT HOW
│ │
Supply Chain Plan to Fulfill
Planning │
│ ▼
Demand Planning Review Demand
Supply Planning Plan Supply
Fulfill Demand
This allows architects to examine the same Enterprise Domain from two complementary perspectives.
This is an important area where confusion can arise.
Enterprise Domains are not part of the APQC Process Classification Framework hierarchy.
Enterprise Domain is a concept used within SAP Reference Business Architecture.
The SAP RBA Business Process Model, however, is based on the APQC Cross-Industry Process Classification Framework (PCF), and business activities can be aligned with relevant APQC activities.
The relationship can therefore be understood conceptually as:
SAP Reference Business Architecture
│
▼
Enterprise Domain
│
▼
Business Process Model
│
▼
Business Activity
│
▼
APQC PCF Alignment
APQC PCF provides a standardized reference taxonomy for classifying and comparing Business Processes.
Enterprise Domains and APQC therefore do not compete with each other.
They serve different architectural purposes.
Another important principle is that an Enterprise Domain should not be mapped directly to an SAP product.
For example:
Supply ≠ SAP S/4HANA
An Enterprise Domain belongs to Business Architecture.
SAP S/4HANA and SAP IBP, on the other hand, are solution components within Solution Architecture.
There are additional architectural layers between them.
Conceptually:
Enterprise Domain
Supply
│
▼
Business Domain
Supply Chain Planning
│
▼
Business Capability
Demand & Supply Planning
│
▼
Solution Capability
Demand Planning
Supply Planning
Response Planning
│
▼
Solution Component
SAP IBP
This distinction enables a Business-Driven Architecture.
Instead of saying:
“We want to implement SAP IBP, so let’s define our Demand Planning process.”
the organization can start with:
“We need a stronger Demand Planning capability to achieve our business objectives. Which solution should enable that capability?”
SAP IBP can then be evaluated as a solution for realizing that capability.
Enterprise Domains can be particularly useful during the early stages of a global SAP transformation.
Consider an automotive Tier 1 supplier facing the following strategic challenge:
“Improve the responsiveness of the global supply chain to increasing EV demand volatility.”
Instead of immediately discussing SAP IBP or SAP S/4HANA functionality, the organization can first identify the relevant Enterprise Domain and narrow the transformation scope.
Business Strategy
“Improve responsiveness to EV demand volatility”
│
▼
Enterprise Domain
Supply – Fulfill Demand
│
▼
Business Domain
Supply Chain Planning
│
▼
Business Capability
Demand Planning
Supply Planning
Inventory Planning
│
▼
Capability Assessment
│
▼
Target Architecture
│
▼
SAP IBP / S/4HANA / PP/DS
This approach allows the organization to define the transformation scope from Business Strategy rather than from SAP products.
Enterprise Domains can also help structure a multi-phase global SAP program.
For example, an organization might decide that Phase 1 should focus primarily on:
Supply + Corporate
while Product & Service and Customer are addressed in later phases.
Enterprise
Product & Service Customer
△ △
│ Future │ Future
│ │
Supply ★★★★★ Corporate ★★★★☆
Phase 1 Phase 1
• SCM Planning • Finance
• Procurement • Controlling
• Manufacturing • Treasury
• Logistics • Management Reporting
Within the Supply Domain, the organization can then prioritize Business Domains.
| Business Domain | Priority |
| Supply Chain Planning | High |
| Sourcing & Procurement | High |
| Manufacturing | High |
| Supply Chain Execution | High |
| Service Delivery | Low |
The analysis can then continue down to individual Business Capabilities.
Capabilities can be assessed using criteria such as:
Strategic Importance × Current Maturity × Transformation Need
This provides a Business Architecture-based foundation for prioritizing the SAP transformation roadmap.
A global SAP transformation typically involves many different stakeholders:
Each stakeholder views the transformation from a different level of detail.
Enterprise Domains can provide a high-level common language connecting these perspectives.
Enterprise
│
▼
Enterprise Domain
│
▼
Business Domain
│
▼
Business Capability
│
▼
Business Process
│
▼
Business Requirement
│
▼
Solution Capability
│
▼
SAP Solution
Executives can discuss the transformation in terms of Enterprise Domains and Business Capabilities.
Business teams can work with Business Processes.
IT teams can work with Solution Capabilities and SAP solutions.
The critical point is that these perspectives can be traced within the same architecture.
This is one of the major benefits of using SAP Reference Business Architecture.
One final consideration is that Enterprise Domains should not be confused with organizational structures.
For example:
Supply Domain
≠
Supply Chain Division
The Supply Domain may involve Procurement, Planning, Manufacturing, Logistics, and multiple other organizational units.
Similarly, the Corporate Domain can involve Finance, HR, IT, Strategy, Risk, and other functions.
Enterprise Domains therefore describe:
“Which areas of business value does the enterprise need to perform?”
rather than:
“Who performs the work?”
This distinction is particularly valuable for global organizations, where organizational structures may differ significantly across countries, regions, and business units.
A common Business Architecture can remain stable even when local organizational structures vary.
Enterprise Domains can serve different purposes depending on the stakeholder.
Enterprise Architects can use Enterprise Domains to connect Business Strategy with Business Capabilities, Business Processes, and ultimately Solution Architecture.
The key question becomes:
“Which parts of the enterprise need to be transformed to achieve the business strategy?”
SAP Program Managers can use Enterprise Domains as a high-level structure for defining Transformation Scope.
The key question becomes:
“Which areas of the enterprise are included in this SAP transformation program?”
Business Process Owners can use Enterprise Domains to understand how their individual processes relate to broader Business Capabilities and end-to-end processes.
This helps move process design away from local optimization toward an end-to-end business perspective.
Enterprise Domains in SAP Reference Business Architecture provide high-level anchors for structuring and understanding the enterprise from a Business Architecture perspective.
SAP RBA uses four Enterprise Domains:
Product & Service – Develop Products and Services
Customer – Generate Demand
Supply – Fulfill Demand
Corporate – Plan and Manage the Enterprise
The important point is that Enterprise Domains should not be treated as SAP product categories.
Instead, they provide the starting point for connecting:
Business Strategy
↓
Enterprise Domain
↓
Business Domain
↓
Business Capability
↓
Business Process
↓
Business Requirement
↓
Solution Capability
↓
SAP Solution
This traceability enables organizations to connect Business Strategy with Solution Architecture.
For global SAP transformations, Enterprise Domains provide a common language for defining scope, identifying transformation priorities, assessing Business Capabilities, and aligning business and IT stakeholders.
Most importantly, they change the starting point of the conversation.
Instead of beginning with:
“Which SAP products should we implement?”
organizations can begin with:
“Which areas of our enterprise need to change, and why?”
That shift—from a product-driven discussion to a business-driven architecture—is one of the most important reasons to understand Enterprise Domains in SAP Reference Business Architecture.
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.
Many Architecture Repositories get built, then quietly abandoned. This article explains the eight components defined…
A practical guide to accelerating EA with generative AI: core principles, a 12-week TOGAF ADM…
Forecast and call-off integration, provisional pricing, chargeable subcontracting, kanban, and acceptance matching. This article maps…
ERP implementation in global manufacturing requires critical decisions about ERP scope, surrounding applications, global standardization,…
Measure SAP S/4HANA ROI over just three years and you will mostly see cost. This…
Explore how SAP Digital Manufacturing supports FPC production, including quality management, traceability, S/4HANA integration, implementation…