Master Data Integration: Customer Expectation and Business Challenges

[former_member361561]

Introduction

Master data integration across business applications is pivotal to SAP Integrated Intelligent Enterprise strategy. Vision for master data integration strategy is to move away from ‘spaghetti’ like point to point integration to a ‘Star’ shaped hub and spoke model as depicted in the pictures below.

 

              

Credit: SAP Cloud Platform  Master Data Integration services Positioning deck

 

There are many advantages that a start shaped integration offers. To list a few:

 

• Significant reduction in maintenance effort


• Quick deployment for new applications


• Centrally managed distribution of data ensuring consistency

 

These advantages come with challenges. I would like to highlight few of the expectations and related challenges via these blog post based on interaction with various parties (SAP internal consumers/ external customers) with shared interest

 

 

Expectation: Aligned data model across integrated applications

 

 

Consider the above picture represents customer enterprise landscape with three SAP application in i.e. A, B and C. In order to enable integration, all three applications need to agree on a common data model for master data objects. This is represented by the intersection b/w these three applications as ‘core attributes’ . This needs to be supported centrally by master data integration layer.

 

In addition to core attributes, A and B has further overlap represented by ‘attributes common across A and B’. Since A and B are SAP applications, master data integration layer needs to handle these set of attributes as well. This is where the complexity starts. Consider the following challenges:

 

Challenge 1: Support for complete S/4 HANA data model

• It is not uncommon for SAP customers to have multiple S/4 HANA (or ERP) systems in their landscapes (for e.g. managing different geographies) which needs to integrate.


• Customers also have SAP master data governance solution in their landscape in hub deployments managing data across multiple ERP systems.

 

Thus, intersection b/w A and B can be a ‘union’. Thus, master data integration layer should inherently provide a way to address complete data model supported by S/4 HANA.

Challenge 2: Requirement for data filtration

 

Some attributes shared by A and B may not require by C. Such attributes should be filtered out while replicating data to C. Since we are still treading in standard SAP territory, this feature should be available out of the box.

 

e.g. In a typical lead to cash scenario, SAP front end applications create multiple prospects (based on IP address, cookies etc.). These prospects may not be required in back office ERP systems as there is no transaction that has taken place and hence should be filtered out.

Another e.g. could be that sales related data for a product which is relevant for applications driving lead to cash scenario is not required for procurement (source to pay scenario).

 

Challenge 3: Manage data consistency during integration

 

Managing consistency entails multiple  challenges as listed below:

 

• In the Venn diagram, since C only need a subset of data relevant for integration incoming update from C contains limited set of attributes for a master data object only. Here existing data for the master data object should not be overwritten. Consider the following e.g. to understand this better:

• 
  
  
  
  • System A replicated object 1 to master data integration layer. Object 1 has bank information.
  
  
  • System C does not support bank information. When object 1 updates are received from system C, bank information received earlier should not be lost in master data integration layer.
  
  
  
  

• Now consider C supports another set of attributes let’s say address and has purpose fully deleted it. C’s expectation would be that address for object 1 in master data integration layer is overwritten. It should be possible for C to differentiate this from action mentioned in first challenge.

• Continuing from previous requirement, let’s go one step further. consider C sends address but not a sub attribute for e.g. street number to master data integration layer. Here C should be able to specify whether

• 
  
  
  
  • C has deleted street number and wants existing entry to be overwritten
  
  
  • C doesn’t have street number in their data model thus it is excluded from inbound message. In such a scenario, existing street number should not be overwritten.
  
  
  
  

 

• Now let’s imagine another scenario wherein there are multiple addresses. Some applications support multiple addresses while others don’t.  Thus, C while sending updates should be able to specify whether
  
  
  
  • C has deleted some address and wants existing entry to be overwritten
  
  
  • C does not support address and existing entry should not be overwritten
  
  
  
  

 

• Another variation of previous requirement could be that although C does support multiple addresses, but customer has has purposefully filtered out certain addresses from replication to C. Master data integration layer has to make sure that it refers to such filters and avoid data overwrite.

In a nutshell  it is critical to enable applications to communicate with ‘patches’ of data and not always full scope for a given master data object.

Conclusion

I would like to conclude here for this blog post. I hope I am able to highlight the complexity of managing customer expectations w.r.t. aligned data model and the challenges it entails. In the next one, I ‘ll try to cover the expectations and challenges with  extension scenarios ( highlighted as complement in the Venn diagram).