Skip to Content

Getting Started with SAP NetWeaver Master Data Managementand SOA – if you have been reading about enterprise computing lately, there is very little chence you managed to avoid hearing these words.They are considered two of the pillars of a new enterprise computing paradigm. They both have a very important,basic feature in common – they aim at standerdisation.

One of SOA’s goals is to standerdise your business process. Write the required functionality once and accesses it by many systems, using a uniform, well defined manner. MDM’s role is simialar – standedize your enterprise’s information. Import and maintain data in one central repository, keep a single version of the truth, a consistent metadata of your master objects – customer,vendor,product.

Using both of them together is obviuos – if your services are standard, they should operate on your standard information. There is not much sense in having a single service access multiplle data sources.

A simple example would be updating your customer information. Assuming you have several backend systems (CRM and ERP instances and a few legacy systems) and you decide to take the SOA approach, you would write a webservice that updates your customer informaiotn. Your webservice, once invoked, would have to be aware of all your beckend systems, and more importantly, would have to know each sytems’ own customer data model. Any change to that model must be reflected in the webservice. In a real hetrougenous environment, implementing SOA that way is literly impossible.

And this is were MDM comes into play. Since MDM is designed to manage information coming from multiple sources, it is the right  contact point between your webservice and your information. The webservice updating your customer data will need to access only a single system – your MDM. Mapping your MDM customer data structure to that of your backend systems is done once in MDM. Once the webservices completed  updating your MDM, it has completed its role and should not care about updating all those backend systems. That part is handled by MDM .

In addition to the integration presented above and is discussed in graeter details by this articel , I would like to suggest another moviation for implementing MDM as part of an SOA initiative – integration to multiple third party service providers.

I discussed this issue in depth in my article Enterprise SOA and MDM: Multiple Service Providers Framework . Third party integration of SAP systems with it’s partners has been one of the major strength SAP’s offering. The ecosystem SAP built with it’s partners enabled SAP’s customer to get great value for their SAP investment. ISVs would usually complement SAP’s offering with specific industry solutions as well as information services. The connectivity between SAP backend systems and the 3rd party software was historically implemented using customized connectors that were provided by the ISV’s. The ISV had to write connectors for each of SAP’s systems –one for ERP, another for CRM and possibly others to non-sap systems, in order to provide a truly comprehensive solution. And this is exactly were integrating MDM into an SOA initiative shines – you no longer have to implement several connectors to be able to consume services by multiple back end system. Instead, the service provider has to expose his functionality only once,as a web service. This webservice needs to be consumed only  by MDM. MDM acts as a gateway between the 3rd party service providers and the backend system requiring information services.

We can take this idea even further – since we have MDM holding the “single version of the truth” – a unified view of your master data objects, you can have multiple services act on those objects in a standard, reusable manner. In such en environment, we are not limited to a single service provider for a specific service – each ISV can easily implement his own webservice to provide the specific  functionally. Deciding which of the service providers to request the service from can be done based on clear business rules. A good example we will use in future posts is  address cleansing service – you can have multiple systems requiring such a service and this service can be provided by multiple ISV’s (SAP surrently has partnerships with several such address cleansing service providers).


Placing MDM between those backend systems and service providers enables SAP and its ecosystem to offer a vast array of services while providing reusability and flexibility in choosing the service provider.

Our MDM now is a mega-gateway, connecting multiple backend systems to multiple service providers. In my next post, I will provide a detailed example of how the team I am part of (SDS-Strategic Data Services) has implemented this framework to provide address enrichment services from multiple vendors.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply