Master Data Integration: Customer Expectation and Business Challenges Part 2

Introduction

This blog post in in continuation of  my previous entry I’ll try to address expectations  from customers regarding  business extension scenarios (as depicted by section D in the below diagram)

data model

Challenge: Capability to define extended attributes centrally for the entire customer landscape

Many SAP applications offer capabilities to define business extensions. However this is not done centrally resulting in the following gaps:

• Since business processes span across multiple SAP applications, customers need to duplicate this effort of extension definition multiple times.

• In the point to point integration world, applications integrate in multiple ways (iDocs, SOAP, OData , REST interfaces).  Each interface needs to be adopted to address extension needs.

• There is additional effort required to locally map these extensions in individual applications.

Maintenance and scalability of such a distributed integration design becomes a challenge. Thus customer expect that there should a central capability that offers

• Centrally enable/ disable extensions.

• Define relevance (inclusion/ exclusion) for individual applications in the landscape.

• Distribution of extensions to all applications local persistence.

• Distribution of extensions to all integration interfaces.Centrally defined interfaces in the star shaped integration model should also make this easier.

Challenge: Capability to control integration flow based on extended attributes

In a distributed landscape, not all extended master data attributes are required across every business process.It should be possible for customers to include/ exclude extended attributes for individual applications. For e.g. extension created for a supplier should be excluded from lead to cash flow.

It should also be possible for customers to control replication of business objects based on extended attribute. For e.g. consider the below flow

Customer has 4 systems in the landscape. Due to regional restrictions, it is required that data replication is limited i.e. Data from ABC should only be distributed to GEH and vice versa.  In order to resolve this conundrum, extended attribute ‘Business System’ is created to capture system of origin.

It should be possible for customer to control the distribution of data as depicted in the below picture.

If the picture above, extension ‘Business system’ should act as a filtering criteria to ‘control’ replication of data.

Challenge: Capability to Plug In extended logic in the integration layer

Customers  need a way to add value to the data during replication. Below mentioned examples can illustrate further on this requirement

• Screening of customer/ supplier data against watch list for a  particular geographical region

• Enrichment of data in the central layer before it can be distributed across the landscape

• Data validations for bank/ payment card information, tax information etc.

In order to do this, it should be possible to ‘plug in’ external services to the central data layer to carry out requisite operations.

Conclusion

No customer that I have interacted with so far doesn’t face one or more of the above mentioned challenges to run their business processes.  This is a key value driver and presents a unique opportunity for SAP to address long existing pain points. 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. data extensions in a distributed landscape.