Federated Master Data Governance

Federated Master Data Approach

For companies with complex system landscapes, it can be challenging to manage their master data. 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 Centres, the address of a business partner, … Application data is related to specific applications, like for example Sales Organization data, plant-specific data, company code, … It can be difficult to centrally harmonize this application-specific data and translate it back de-centrally. To avoid these kinds of complexities, the federated master data approach was introduced. This means setting up a master data management approach in such a way that core data can be governed centrally and shared with all relevant applications, while application-specific data can be governed there where it is best understood (de-centrally).

Required components

To apply the federated master data approach, there are three main components provided: SAP One Domain Model (ODM), SAP Master Data Integration (MDI), and SAP Master Data Governance, Cloud Edition (SAP MDG CE). During this blog, we will detail the uses of each of these components.

SAP ONE DOMAIN MODEL

SAP One Domain Model is a harmonized language to easily share business objects between different applications without the need for application-specific replication solutions. Business objects will be automatically mapped from an SAP solution to the corresponding One Domain Model fields. The translation between each application to another one is standardized, and out-of-the-box understood. The business objects are defined in the Core Data Services format (CDS). It is important to know that it is not the purpose to replace the existing data models with one standard data model because there are too many context-specific fields.

To consult which fields are supported, the data model is available in the SAP API Business Hub which can be found here: https://api.sap.com/sap-one-domain-model

SAP MASTER DATA INTEGRATION

When we talk about SAP’s integration strategy, the movement to an intelligent enterprise, we think about more out-of-the-box integration possibilities between different domain models. The purpose of SAP is to align these different domain models like S/4HANA, SAP Concur, SAP Ariba, … This integration strategy fits in the federated master data approach.

SAP MDI is a service available on the SAP Business Technology Platform and offers synchronization of master data across different SAP applications and is the central entry point for data sharing and distribution. MDI uses the data models defined in SAP One Domain Model. It gives the responsibility to certain applications to control the process of creating or changing master data.

MDI splits integration and governance as a process. SAP MDG is the core application to hold the master data governance process, while MDI takes care of the integration.

The current features are:

• Distribution of Master Data:
  • You can specify a distribution model that allows you to identify which systems have access to view or modify specific data
• Data Editing by Multiple Systems:
  • Multiple systems can edit the same data
• Read Access Logging:
  • You can monitor and log read access to sensitive data

SAP MASTER DATA GOVERNANCE CLOUD EDITION (SAP MDG CE)

This is the new complementary deployment option of SAP Master Data Governance, that will pave the way for the federation of master data maintenance. It allows organizations to start their master data management initiatives with a low-entry barrier, or organizations that already use SAP Master Data Governance to adjust from fully centralized master data management to a more modular approach.

The SAP MDG Cloud Edition will be responsible for the management of the core master data, so it will not contain Organizational Level data, like Sales Organizations, Purchasing Organizations, or Company Codes. The Organizational Level data is seen as application-specific data, aligned to the S/4HANA Data Model. SAP MDG Cloud Edition will focus on the governance of the Core attributes, rather than application-specific attributes.

At this moment, only Business Partner core attributes are supported:

On the SAP MDG Cloud Edition roadmap for 2022, we can already see some planned extensions to include:

• Address versions
• Address-independent communication data
• Relationships
• Payment cards

Currently, SAP has no plans to include application-specific master data attributes, like Organizational Levels, into the SAP MDG Cloud Edition since SAP MDG on S/4HANA is still the recommended deployment option to serve that purpose.

Following are the current features:

You can catch a glimpse of the SAP MDG Cloud Edition underneath:

EXAMPLE USE-CASE

Let us take a simple example where the federated approach was applied: The creation of a new supplier, starting from SAP Ariba. Following are the components that are available in the landscape:

• SAP Ariba: where we will create a new supplier
• SAP Master Data Integration: takes care of the synchronization of the master data between all the systems and is based on the SAP One Domain Model
• SAP S/4HANA with MDG: responsible for the procurement data
• SAP MDG Cloud Edition: responsible for the core data

1. In SAP Ariba a new supplier is created with core data and some procurement data as well.
2. The supplier is persisted in SAP Ariba and can already be used for follow-up processes.
3. The newly created supplier is replicated to MDI. The process receives the status ‘in validation’ because the data arrives from SAP Ariba which is not the data owner. In this example, SAP MDG CE is the data owner for the core data. The SAP S/4HANA system is the data owner for the procurement data.
4. MDI persists the BP and recognizes that the record does not come from the core data owner and sends the record to SAP MDG CE, which is the core data owner.
5. The arrival of the BP in SAP MDG CE triggers a master data process that validates the core data and executes a duplicate check. When the system finds a duplicate, or the validation fails, a master data specialist is notified that manual processing may be required. In this case, everything went successfully, so MDG CE sends the core data back to MDI.
6. MDI stores the updated core data, but the S/4HANA data has not yet been verified by data owners, so the status is still ‘in validation’. MDI replicates the BP to the corresponding data owners, the S/4HANA system in this case because some procurement data belongs here.
7. In the S/4HANA system, a process to verify the procurement data is started. The relevant teams to validate the data, receive tasks in their workflow inbox. They start the verification of the data, and if necessary, they correct or complete the data.
8. After the validation is successful, the data is sent to MDI again where it is updated.
9.  All data has been verified by the corresponding data owner, so in MDI the status of the BP changes from ‘in validation’ to ‘active’. 
10. This triggers the replication of the new BP record to all applications that are connected to MDI.

MDG Cloud Edition vs. MDG S/4HANA

As mentioned before, SAP MDG Cloud Edition is an additional deployment option that organizations can choose from. It won’t replace the SAP MDG on S/4HANA.

Both deployment options each serve their purpose:

Which deployment option should a company use?

CENTRALLY MANAGED DEPLOYMENT

This is still the best option for companies who want to manage their master data centrally, for a specific data domain, like for example CRM for customer data or MDG based on the S/4HANA data model.

FEDERATED

It will be interesting to think about the federated master data approach when there are multiple applications in a landscape. For example Customer Cloud, Marketing Cloud, S/4HANA, third party systems, …

Use cases:

•  A company completed an acquisition and received new parts into their landscape. These new parts are not yet harmonized to the rest of the company, while other existing parts are based on a centralized S/4HANA system. For these new parts they can federate out to a second MDG system, optimized for these new business units, and they can keep track on the corporate level, to not create duplicates for example.
• If a company has difficulties running its current MDG system, because of some complex customizing synchronization (Identifying the relevant data, determining where to maintain it, and deciding how the synchronization process is managed). In this case, they might think about splitting it into two parts. Instead of heaving one MDG installation, they might carve out some of that and put it in a separate MDG box and then federate it with the help of MDG Cloud Edition).

As there are many aspects that could influence the best deployment option for your company, we might be able to assist you in this journey.