Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
MarkusKuppe
Advisor
Advisor









Implement a network of MDM solutions that is cost effective, that is aware of your applications, and that really understands the concept of federation.

This gives you higher flexibility at lower cost, allowing you to do corporate MDM at a level you may not have thought ever to be affordable.

 

You may have seen my recent blog post Extended portfolio and additional deployment options for SAP Master Data Governance or the News Release in which we announced the launch of SAP Master Data Governance, cloud edition. If you missed it, please watch this video or take a look at this article to learn more about the concept of federation and about the new version of MDG.

In her blog post Harness the Agility and Flexibility of a Cloud-Based Master Data Management Solution, my colleague Corrie Brague discussed how companies just starting off with master data management, and companies that already have an existing, on-premise master data management solution can benefit from SAP MDG, cloud edition and from the concept of federation. Today, I would like to dig a little deeper and discuss the specifics of what could be in it for you.

How does federation provide value?

Before looking at companies’ different journeys towards federation, let’s go back to the value proposition of federation itself and why you should even strive for it.

Many companies use one single, global MDM instance to centrally manage all master data for the enterprise in that one system. Also, most companies using SAP MDG on SAP S/4HANA today do exactly that. But for some more heterogenous companies, the extent to which they can really drive their corporate-wide MDM initiative with this approach is limited. Typically, they have to limit the breadth of the data model in MDM, or they have to limit the coverage of all business units. Why is that the case?

Just to be clear, the following is true regardless of which software you use for your MDM program: What we often find in heterogenous organizations is that there is a certain set of core attributes for a given master data domain, like name, address, and some global attributes of a customer. These core attributes can be harmonized and used homogenously across the complete enterprise. In contrast, there is a very broad set of application-specific attributes, that are defined very differently per application or per business unit or geography.


When such companies try to establish an enterprise-wide master data management discipline, these companies often struggle to find the single harmonized approach that meets all stakeholder requirements for all these many attributes. Often, the application-specific master data attributes are those that steer how the value generating business processes are carried out for these master data objects. The more heterogenous an enterprise is, the more it is the case that the business processes are configured differently for different business units. That is why it is so difficult to harmonize all these application-specific attributes at corporate level.

The organizations struggle. They can harmonize core attributes, but they cannot harmonize the needs for all application-specific attributes across all diverse business units. This limits their scope for an enterprise-wide master data management strategy. As mentioned above, they either have to limit the breadth of the data model, or they have to limit the coverage of more diverse business units.

Federation of data governance solves this problem. It separates core master data attributes (harmonized across the enterprise) from application master data attributes (that are aligned for each harmonized unit of the enterprise). Federation takes away the burden of upfront harmonization where it is hard to achieve. It eliminates the need to translate corporate master data back to local understanding. You just define which units are so diverse that a separate instance of an “Application MDM” is justified, and then you federate all MDM systems together with the one corporate system for core attributes.


The picture above shows a sample company that has three diverse business units. Let’s say one unit is an automotive supplier with just-in-time delivery, one unit produces household tools that are made-to-stock and sold in departments stores, and the third unit produces high-tech electronics. There is one corporate MDM system for the core attributes, and, in addition, each business unit has exactly one MDM system for the application-specific aspects of the master data. And then there is perhaps one more application MDM system for, let’s say, the central procurement department and corporate financials.

Let’s assume the automotive supply unit wants to introduce new measures for predictive quality. They want to introduce sensors and cameras along the assembly line that send a data stream to an IoT platform, which uses machine learning to detect quality issues, already before the products are sent to the customers. They find out that some changes to master data structures are needed to support this new process.

Their most important customer is perhaps urgently requesting better quality, and the unit knows how to achieve it. The last thing they want to do is to start an enterprise-wide alignment of master data models. They want the freedom to make these changes in their own unit’s Application MDM system whilst keeping the link to the corporate MDM to continue to profit from central benefits, e.g. global purchasing power.

Why could federation be the more effective approach for you?

Let’s assume we all agree that there is a benefit in the agility and speed that a federated approach provides. But when you look at this architecture, having several MDM systems instead of just one might look like a very expensive approach at first glance. However, when it’s done right, the total cost of ownership of such a federated landscape of MDM systems can actually be lower than the cost for one corporate MDM system.

The “secret sauce” is the way you implement this federated landscape. The first aspect is that you should use one central MDM solution for the core attributes that builds on an industry proven standard data model and can be consumed very cost-effectively in the cloud. This is exactly where we see the value proposition of SAP MDG, cloud edition.

The second and very important aspect is that the Application MDM solutions must be very aware of the specific of the business applications for which they are managing the master data. That is, the Application MDM solutions need to have an out-of-the-box understanding of the usage of the master data in the applications and they need to come with a definition of what makes high-quality master data that can directly be used in the applications. This is exactly what I meant in my earlier blog post when I said: you should manage the master data at the place where it is best understood. (The fact that you can co-deploy SAP MDG on S/4HANA on premise today, and that we plan to evolve MDG capabilities that can be consumed directly on SAP S/4HANA Cloud, will provide real value here. Especially, when you use SAP MDG on S/4HANA as an Application MDG in a federated MDG context.)

The third aspect is that these MDM solutions need to be aware that they are not alone the universe. They need to behave as being part of a federated network. They need to understand that they only own parts of the master data, and that other systems own other parts of the master data, and that MDM processes need to go hand in hand across systems, to achieve master data that is complete and valid in a full corporate sense. The concept of master data ownership that SAP is introducing with SAP Master Data Integration and the fact that SAP MDG shall make use of this concept will support this aspect.

If these three aspects are met, the TCO of a Federated MDM approach can be lower than that of one corporate MDM system. This is because you can eliminate the burden of upfront harmonization where it is hard to achieve. You can remove the need to continuously translate corporate master data back to local understanding. And ideally, the Application MDM capability can be co-deployed directly on the applications, and you can spare most of the costs to run Application MDM systems, if they can reuse the existing application infrastructure.

To summarize: if you can implement a network of MDM solutions that is cost effective, that is aware of your applications, and that really understands the concept of federation, then you can get higher flexibility at lower cost. And this will allow you to do corporate MDM to a level that you perhaps didn’t expect to ever become affordable.

Are you using SAP MDG today?

Let’s discuss what this means for companies that already use SAP MDG today. As discussed, most of these companies use MDG to centrally manage all master data for the enterprise in one system.

Hoping that many aspects have already become very clear in the section above, I would like to provide a bit more precise food for thought here. If your company already runs SAP MDG today, federation, for example, allows you to:

  • Extend your MDM initiative to areas of your enterprise that you have not been able address so far, by implementing another Application MDG system and federating it with your existing system

  • Reduce the cost of your running MDM initiative by dividing one existing SAP MDG system into two (or even more) Application MDG systems (and hence reduce the costs for ongoing harmonization, customizing synchronization, separate system operation, etc.)

  • Start your MDM journey to the cloud by adding SAP MDG, cloud edition and then federating additional MDG systems that will be increasingly consumed in the cloud (along with the speed of your applications that are transitioning to the cloud)


As you can see, all of these approaches will fully leverage all your earlier investments that you have already made in SAP MDG on SAP S/4HANA. (Oh, by the way, if you are still on SAP MDG on SAP ERP 6.0, please plan for a move to MDG on SAP S/4HANA for that system at some point in the future.)

You are not yet using SAP MDG?

Let’s discuss how you can get to a federated MDG landscape in case you are not using SAP MDG today.

Obviously, you could start with one SAP MDG on S/4HANA for some parts of your organization. And you could decide whether or not to immediately accompany this with SAP MDG, cloud edition for a clean separation of core and application attributes. Then, you’d follow the path outlined above.

However, there is another option you may find attractive: You could simply subscribe to SAP MDG, cloud edition as a very quick start to master data management – an easy and very affordable Software-as-a-Service, multi-tenant system. And then there are ways to scale out. Perhaps you will need a central platform for additional core attributes, perhaps for your own self-defined, additional domains. We plan to also offer SAP MDG, cloud edition as a Platform-as-a-Service with the flexibility to extend it and to use your self-coded business logic according to your needs.

From that starting point of using SAP MDG, cloud edition, you can later further federate beyond core attributes, into the application-specific attributes. Supported by the ownership concept in SAP Master Data Integration, you can involve the necessary applications that contribute to master data. And wherever you want to apply additional quality assurance to certain master data, you can involve application-specific deployments of MDG.

Do you want to see and feel SAP MDG, cloud edition?

Some of the topics I mentioned above, like ownership and federation, are still evolving along our roadmap. But you can see SAP Master Data Governance, cloud edition in action, already today.

There are two videos to give you a sneak peek: One shows the creation of a new business partner, the other shows how you can analyze data quality and remediate found errors in SAP Master Data Governance, cloud edition.

But that’s not all: I would like to invite you to access the solution for free for up to 30 days. Please refer to this blog post by Christian Geiseler or directly progress to the SAP Master Data Governance, cloud edition Trial Registration Page.

For your convenience, here’s a list of the links to the most important assets:

Keep following the MDGUpdates2021 tag to see more SAP Community blog posts about SAP Master Data Governance. And please feel free to join the SAP Community Call on SAP MDG, cloud edition on March 11: registration via this link.

For more information on SAP Master Data Governance on SAP S/4HANA, please see: