Data Mesh with SAP Business Technology Platform Part 3 – SAP Master Data Governance
*** Please be aware that the Scope of the SAP One Domain Model (ODM) was expanded and therefore the ODM-related content of this blog post has been updated. Refer to the following blog post: “Harnessing Half a Century of Knowledge: SAP’s Journey of Enriching APIs with Business Metadata.”***
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:
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:
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:
The author would like to thank Frederik Michael Hopt for the collaboration on this topic and his contributions to this article.
- Further Information:
- More than just a hype: Data Mesh as a new approach to increase agility in value creation from data
- Data Mesh with SAP Business Technology Platform Part 1 – SAP Data Warehouse Cloud
- Data Mesh with SAP Business Technology Platform Part 2 – SAP HANA Cloud
- Data Mesh with SAP Business Technology Platform Part 3 – SAP Master Data Governance
- Data Mesh with SAP Business Technology Platform Part 4 – SAP Data Intelligence Cloud
- Data Mesh with SAP Business Technology Platform Part 5 – SAP Analytics Cloud
- Data Mesh Architecture by INNOQ: