Skip to Content
Business Trends
Author's profile photo Wolfgang Albert Epting

Data Mesh with SAP Business Technology Platform Part 3 – SAP Master Data Governance

Summary: In my first blog with the title: More than just a hype: Data Mesh as a new approach to increase agility in value creation from data I explained the four principles of Data Mesh at a high level and mapped some helpful capabilities of the SAP Unified Data & Analytics Portfolio. In the current and subsequent episodes, I will look at individual SAP products and explain in more detail which of their technical capabilities can support the introduction of a Data Mesh. Having started the series with SAP Data Warehouse Cloud and SAP HANA Cloud in the previous blogs, this time I will talk about SAP Master Data Governance and later on continue with SAP Analytics Cloud and SAP Data Intelligence Cloud.

To fully understand this blog, it is at least necessary to have read my first blog or another respective publication to be familiar with the four principles of Data Mesh and to understand why centralized  monolithic data architectures suffer from some inherent problems. Recognize the mention of Data Mesh principles by the fact that they are written in bold


SAP Master Data Governance – Consistent and high-quality master data for your entire organization

SAP Master Data Governance is a state-of-the-art master data management application, providing preconfigured, domain-specific master data governance to monitor and correct potential data quality issues, to centrally create, change, and distribute, or to consolidate master data across your complete enterprise system landscape.  Several of its functionalities and concepts predestine SAP Master Data Governance to be used in Data Mesh scenarios. In the following, I will explain the, from my point of view, most relevant.


Manage (master) data where it is best understood:

At its core, Data Mesh is based on decentralizing and distributing data responsibility to the people who best understand their data. In order to find the right axis of data decomposition, Data Mesh is oriented towards the organizational units like Sales, Procurement, HR, Marketing etc. and assumes that the business domains are responsible for providing the facts of their business as trustworthy data. The resulting artifacts are called source-related or native domain data products because they reflect the daily business managed by operational systems of record.

Treating data like a product, another principle of Data Mesh, on the other hand implies end-to-end responsibility for the domain teams, what also includes the sourcing and therefore the quality of the data in the operational source systems. If we evaluate operational data according to its relevance for the processing of business operations, we can conclude that master data forms the backbone of this complex organism.

To say that a large number of data products will be created using classic master data domains such as customer, supplier, product, material, financials etc., reflects the fact that they correlate with the described organizational units. These are the ones that create the demand for data products in their domain and these are the ones that later become their main consumers. Business data is collected and managed by a large number of enterprises and organizations in SAP systems for decades.

However, we all know that it can be difficult to manage precisely this master data in complex landscapes in such a way that it has the required quality to build professional data products. In general, we can divide master data into two categories, namely: Core master data and application master data. Core Data can be shared between different applications, like for example Workforces, Cost Centers, Addresses of a Business Partners etc.. Application master data is related to specific applications, like for example Sales Organization data, plant-specific data etc.. To avoid complexities caused by centrally harmonizing application-specific data and translate it back de-centrally, we introduced the concept of federated master data management. This means setting up master data management in such a way that core data can be governed centrally and shared with all relevant applications, while application-specific data can be governed decentral where it is best understood.

Federated Master Data Management:

Manage core and application master data where it is best understood

Data Mesh needs Data Quality:

In Data Mesh, the responsibility for ensuring data quality is transferred to the decentralized domain teams (Shift-Left). At the same time, there must be a central instance which defines the standards for the overall data quality. This task is performed centrally as part of Federated Computational Governance and the policies are shared with the domains. Since these are global policies, all data product managers are encouraged to adhere to and assign them. This may be at odds with the ability to quickly build valuable data productions. One motivation is to incentivize them for good data quality. As a result, data product managers have a superior interest in obtaining high quality data from operational systems.

The better the quality of the master data in the source systems, the better the quality of the resulting data products. This chain of causality is a highly valid without further examination or explanation.

SAP Master Data Governance Data Quality Management supports not only measuring master data quality, but also to ensure continuous improvement instead of slow but constant erosion. With AI based mining data quality rules are automatically discovered, and when used at all points of entry of new data as recommended, a situation is created that prevents new bad data from entering. The rules identified by AI are well suited to serve as the basis for quality standards that must be established on behalf of federated computational governance.

The other two archetypes beneath the above mentioned source-aligned are consumer-related or fit-for-purpose and aggregated data products, which profit from good master data quality implicitly downstream because they are built with source aligned data products. Consumer-related data products consist of analytical data transformed to fit the needs of one or multiple specific use cases while aggregated data products consist of analytical data that is an aggregate of multiple upstream domains.

SAP Master Data Governance Data Quality Management:

Measure and analyze data quality to remediate issues


Link business entities to weave a solid Data Mesh:

Data mesh theory advises against highly aggregated data models that depict all facets of a business domain as this severely impairs scalability and flexibility. Instead, domain teams are encouraged to design their own more lightweight aggregates. This seems to contradict the principle of master data management whose idea is to provide a single source of truth.

On the other hand, one of the characteristics of Data Mesh is that data products shall be interoperable. The key to effective composability of data across domains is adhering to standards and harmonization rules that allow data to be easily linked across domains. In order to standardize data products and enable these required interoperability and composability, there must be identifiers that allow universal identification of entities that cross data product boundaries.

Overarching identifiers for entities such as customers, suppliers, products, etc. can only be generated and managed centrally. SAP Master Data Governance also provides valuable services here by generating and managing a universal identifier that can be used to establish interoperability at the data product level.

Another conceptual capability to make interoperability possible is the description of data types that can be interlinked within different data products.

The federated master data approach described above does exactly that by using a “Lingua Franca“, the SAP One Domain Model (ODM), as a harmonized language. Business objects are automatically mapped from SAP and non-SAP solutions to the appropriate One Domain Model fields. Data products immediately understand each other’s translations because they are standardized by the One Domain Model, which is published in the SAP API Hub.

One Domain Model:

“Lingua Franca” for interoperability of data products

The author would like to thank Frederik Michael Hopt for the collaboration on this topic and his contributions to this article.

If you have any further questions about SAP Business Technology Platform or specific elements of our platform, leave a question in SAP Community Q&A or visit our SAP Community topic page.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Frederik Michael Hopt
      Frederik Michael Hopt

      Worth to read it! Take the time!!

      Author's profile photo Wolfgang Albert Epting
      Wolfgang Albert Epting
      Blog Post Author

      Thank you, Frederik.

      Author's profile photo Babitha Sathyanarayanan
      Babitha Sathyanarayanan

      Wonderful Blog Wolfgang!!

      Author's profile photo Wolfgang Albert Epting
      Wolfgang Albert Epting
      Blog Post Author

      Thank you Babitha.

      Author's profile photo Pius Kirrmann
      Pius Kirrmann

      Hello Wolfgang,
      we often find an event streaming backbone (like Apache Kafka) in the architecture of a Data Mesh.
      Events are considered as the interface to the mesh. And "Business facts are best presented as business Domain Events, ...".
      Does SAP Event Mesh (basic or advanced) play a major role in the architecture of a Data Mesh on SAP BTP?
      Kind regards, Pius

      Author's profile photo Wolfgang Albert Epting
      Wolfgang Albert Epting
      Blog Post Author

      Hello Pius,

      thank you for your question.

      The job of a data product is to serve the analytical data of a particular domain with a specific and unique domain semantic. However, for a data product to serve its diverse consumers natively, it must share the same domain semantic, in different syntaxes; the semantic can be served as columnar files, as relational database tables, as events or in other formats. The same semantic is served without compromising the experience of the data consumer. People who write reports consume the data as relational tables. People who train machine learning models consume data in columnar files, and real-time app developers consume the events.

      According to this definition events are one way data products serve consumers. This means that SAP Event Mesh definitly plays a role in the Data Mesh approach.

      Kind regards