What Are Solution Data Architecture Diagrams?

SAP Learning describes the term as follows:

“The term, Solution Data Architecture Diagrams, serves as a generic placeholder for two Data Architecture-related diagrams.”
(Source: SAP Learning – Building Data Architecture)

In other words, it is not the name of one diagram. It is an umbrella term for two diagrams:

Diagram	In a nutshell	Key questions it answers
Solution Data Flow Diagram	Where data flows, from which component to which	Which system is the system of record? Which components does the data go to?
Conceptual Data Diagram	How data entities relate to each other	Which entities exist, and what are their attributes and multiplicities?

Where They Fit in the SAP EA Framework

The SAP EA Methodology groups its core artifacts into four interlinked architecture views (SAP Enterprise Architecture Methodology Guide):

• Capability
• Process
• Data
• Organization

The Solution Data Flow Diagram belongs to the Solution Architecture domain. The same domain also includes the Product Map, Solution Component Diagram, Solution Value Flow Diagram, and Solution Process Flow Diagram (SAP Learning – Discovering the Reference Architecture Content).

According to the same guide, SAP’s Enterprise Architecture Development Cycle is based on TOGAF and tailored to SAP’s needs (SAP EA Methodology Guide). However, the public material does not say which TOGAF ADM phase these diagrams map to. If you come from a TOGAF background, it helps to think of them as diagrams that make the Phase C (Data Architecture) work concrete in terms of SAP solution elements (author’s interpretation).

Why You Need Them: The Purpose

1. Understand How Data Flows and Where It Lives

“Solution Data Flow Diagrams shows typical data flows for key master, transactional and configuration data. It helps with understanding required data and its distribution across the used Solution Building Blocks (Solution Components).”
(Source: SAP Learning)

The first purpose is to show where master, transactional, and configuration data resides and how it is distributed across components.

2. Understand the Context of a Solution

“This diagram is crucial in understanding the context of a specific Solution.”
(Source: SAP Help Portal – Solution Data Flow Diagram)

3. Clarify How Data Relates to Business Entities

“The purpose of the conceptual data diagram is to outline the relationship between data and business entities of the aspired solution.”
(Source: SAP Learning)

The Practical Value for Enterprise Architects (Author’s View)

• A clear system of record: You settle which system owns the data early in design, before it becomes a dispute.
• A complete interface inventory: The data flows you collect become the starting point for your interface list.
• A well-defined MDG and data governance scope: You can decide which data to govern centrally and where to distribute it.
• A shared language for business and IT: Both sides can agree on data ownership, which process diagrams alone do not show.

What the Diagrams Contain

Solution Data Flow Diagram

“A Data Flow Diagram depicts solution components and their implemented, integration-relevant solution data objects. The data flows show the flow of data between the system of records and subsequent solution components.”
(Source: SAP Learning)

Its main building blocks are:

Element	Meaning
Solution Component	A building block of the solution, such as SAP S/4HANA, SAP SuccessFactors, or SAP MDG
Solution Data Object	A component-specific data object. SAP Learning defines it as a Solution Component-specific realization of a Business (Data) Object. It may also cover part of a Business Object or several Business Objects.
Data Flow	The flow of data between two Solution Data Objects in different components. Each end is a Solution Data Object, and data moves from the sender to the receiver.
System of Record	The authoritative system for the data and the starting point of its data flows

It also helps to separate Data Flows from Message Flows:

“Message Flows bundle multiple Data Flows and describe technical details, such as protocol and authentication.”
(Source: SAP EA Methodology Guide)

• Data Flow: the logical relationship, meaning which data flows
• Message Flow: a bundle of Data Flows plus technical details such as protocol and authentication

Conceptual Data Diagram

“The Conceptual Data Diagram can be treated like an Entity-Relationship Diagram, outlining, and describing the information being processed by the aspired solution.”
(Source: SAP Learning)

Like an ER diagram, it uses entities, attributes, and relationships (multiplicities). It does not describe physical tables. It describes how business information is structured.

How to Build Them, Step by Step

Solution Data Flow Diagram in Three Steps

SAP Learning lays out the following three steps (SAP Learning):

1. Identify the Solution Data Objects
   “Specify all (especially integration) relevant Solution Data Objects within the relevant Solution Components.”
   List the data objects in each component, with a focus on those involved in integration.
2. Specify the data structure
   “In context of SAP, the structure shall be provided by One Domain Model (ODM).”
   In an SAP landscape, define the structure according to the One Domain Model (ODM).
3. Specify the data flows
   “Define dependencies between identified Solution Data Objects by specifying the flow of data between relevant Solution Components.”
   Show the dependencies between components and the direction in which data flows.

Conceptual Data Diagram in Three Steps

1. Define the entities: Identify the information objects the solution processes.
2. Define the attributes: Give each entity a clear name, then add attributes and data types. SAP Learning recommends keeping data types simple, such as “number,” “string,” and “date.”
3. Define the relationships: “Mostly, you will design an association between two entities and define a multiplicity.” The association is drawn as a solid line and described with a verb.

(Source: SAP Learning)

Using Them Across an Implementation Project (Author’s Recommendation)

Stage	What to do	Diagrams used
Vision and pre-Fit-to-Standard	Obtain SAP’s reference architecture and narrow it down to your scope	Data Flow (reference)
Conceptual design	Agree on the key business entities and their relationships	Conceptual Data Diagram
Solution design	Confirm the system of record, target components, and integration-relevant data objects	Data Flow (to-be)
Interface design	Turn Data Flows into Message Flows and map them to APIs and iFlows	Data Flow, Solution Process Flow
Migration and governance design	Set data owners, migration sequence, and MDG scope	Both

Real-World Examples

Example 1: Travel to Reimburse (Official SAP Example)

The SAP Help Portal walks through the Travel to Reimburse process in a cloud deployment (SAP Help Portal):

1. The Travel Request component sends a Travel Request data object to Expense Management.
2. Expense Management creates an Expense Report and forwards it to Accounting.
3. After approval in Accounting, an Approved Expense Report is sent back to Expense Management.
4. The system of record is updated, and Employee Self-Service is notified of the approval status.

The SAP EA Methodology Guide lists the components and data objects in this example (SAP EA Methodology Guide):

Component	Key data objects
SAP SuccessFactors Employee Central	Person, Employment, Cost Center, Legal Entity
SAP Master Data Integration	Workforce Person, Cost Center
SAP S/4HANA Cloud	Business Partner, Cost Center, WBS Element, G/L Accounts, Company Code, Exchange Rates
SAP Concur (Travel / Expense)	Travel User Data, Expense User Data, Account Codes, Wage Types
SAP SuccessFactors Employee Central Payroll	Employee, Cost Center, Wage Types, G/L Accounts

What an EA should take away: HR master data is owned by Employee Central and distributed to S/4HANA and Concur through SAP Master Data Integration. The diagram also shows at a glance that even a single expense process depends on master data from three domains: HR, Finance, and Expense.

Example 2: HR Data in Hire-to-Retire (Official SAP Example)

SAP Learning includes an example described as “the Data Flow Diagram for HR Data in the Hire-to-Retire process” (SAP Learning). It is a typical use case: mapping where HR data is created and where it is distributed, from hiring through retirement.

Example 3: SAP Master Data Governance (Official SAP Reference)

An SAP Community blog introduces the reference solution architecture for SAP MDG. It includes a data flow diagram for the Business Partner domain, and a later update added detailed diagrams for the business partner, product, and financial domains in classic mode (SAP Community – Reference Solution Architecture for SAP MDG). This content is published on the SAP Business Accelerator Hub and the SAP Signavio Process Navigator (SAP for Me) (same source). If you are planning an MDG implementation, the fastest route is to start from this reference and tailor it to your organization.

Example 4: Material Master Integration at an Automotive Supplier (Author’s Example)

The following is the author’s own example, based on an automotive Tier 1 supplier.

Starting point: Engineering BOMs live in PLM, production runs in S/4HANA, shop-floor execution runs in MES, and procurement runs in SAP Ariba. Material master data is maintained separately in each system.

Solution Data Flow Diagram (to-be): the data flows

From (data object)	To (data object)	Data transferred
PLM (Engineering Part / EBOM)	SAP MDG (Product, system of record)	Basic material data and engineering attributes
SAP MDG (Product)	SAP S/4HANA (Product, BOM, Routing)	Product and plant views
SAP S/4HANA	MES (Work Order, Material)	Production orders and materials
SAP MDG (Product)	SAP Ariba (Catalog / Sourcing Item)	Product and supplier information
MES	SAP S/4HANA	Production confirmations and consumption

Design decision	Example conclusion from the diagram
System of record	SAP MDG owns basic material data. PLM is the source of engineering attributes.
Target systems	S/4HANA (plant views), MES, and Ariba
Governance	Material creation requests and approval workflows are centralized in MDG.
Interfaces	Four interfaces, PLM→MDG, MDG→S/4HANA, S/4HANA→MES, and MDG→Ariba, are detailed as Message Flows.

Conceptual Data Diagram (excerpt): the relationships

Entity	Relationship (verb)	Entity	Multiplicity
Product	is extended to	Product Plant	1 to 0..*
Plant	holds	Product Plant	1 to 0..*
Product	is component of	BOM Item	1 to 0..*
BOM	consists of	BOM Item	1 to 1..*
Product	is sourced via	Purchasing Info	1 to 0..*
Supplier	supplies	Purchasing Info	1 to 0..*

With these two diagrams, you can settle questions with the business before blueprinting. For example: who creates plant-specific material data, and whether supplier-specific purchasing information should live in Ariba or in S/4HANA.

Best Practices for Enterprise Architects

1. Start from the reference. SAP provides reference architecture content for its Solution Architecture artifacts, including industry-specific versions (SAP Learning). It is faster than starting from scratch and makes your deviations from the standard visible.
2. Focus on integration-relevant data. SAP Learning tells you to cover “especially integration” relevant objects. Do not try to diagram every field.
3. Keep Data Flows and Message Flows separate. Drawing the logical view (which data) apart from the technical view (protocols, authentication, APIs) lets you review each with the right audience.
4. Name things according to ODM. In SAP landscapes, aligning structures and names with the One Domain Model makes it easier to map your design to SAP APIs and standard content.
5. Use them with the other diagrams. Combine them with the Solution Component Diagram (structure) and the Solution Process Flow Diagram (behavior) so you cover structure, behavior, and data together.

Summary

• Solution Data Architecture Diagrams is the umbrella term for two diagrams: the Solution Data Flow Diagram and the Conceptual Data Diagram.
• The Solution Data Flow Diagram shows how data flows from the system of record to the other components.
• The Conceptual Data Diagram shows, like an ER diagram, how data relates to business entities.
• In SAP implementations, the most effective approach is to start from SAP’s reference architecture, tailor it to your to-be design, and then carry it into interface, MDG, and migration design.

Making data ownership visible early lays the foundation for better data quality and fewer integration problems in your S/4HANA implementation.

Reference Links

• SAP Learning – Building Data Architecture
• SAP Help Portal – Solution Data Flow Diagram
• SAP Enterprise Architecture Methodology Guide (PDF)
• SAP Learning – Discovering the Reference Architecture Content
• SAP Community – Explore the Reference Solution Architecture for SAP Master Data Governance

---

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.

---

Back to Top