cancel
Showing results for 
Search instead for 
Did you mean: 

Local attributes - global attributes tradeoff

Former Member
0 Kudos

Hi, MDM experts.

Can you, please, share your experience on business partners repository modeling.

I build custom business partners repository. While creating it I came to a question - whether local system attributes of business partner should be modelled in that repository?

Intrinsic attributes like Full Name, State Identity Number and so on should be definitely modeled. Attributes specific to our organization but those that span many of our systems should also be modeled I think.

But what's about some specific attributes that are relevant only for one of the systems being integrated? To be concrete, imagine we have SAP ERP system as one of the systems in landscape and such attribute of our business partner as 'Purchasing organization'. In our case this table is SAP ERP specific and none of our other systems have such entity in their data model.

<b>The question is - is it reasonable to have local system attributes and lookup tables implemented in central MDM repository?</b>

If yes then isn't our repository going to be overloaded with all that local attributes and lookup tables of every client system?

If no, then how should process of central creation of business partner look like? The problem is in this case Creator won't be be able to assign all attributes he would like to and he will have to login to each of local system and assign these values after central creation. Moreover, client systems can refuse to create new record automatically in case some of attributes are missing. For example such situation is typical for Idoc inbound processing .

Have you any suggestions on streamlining the data model and BP central creation process ?

Regards,

Vadim Kalabin

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi vadim,

These are my thoughts on your issue.

I feel both the attributes should find place in the same repository.

This is not going to overload the system. In some typical MDM Implementation the volume of Main table records will very huge and the Local and global attributes will only occupy a less share only on the total records.

Also the practice is that MDM DB Server and the core server runs separately.

Pl find if this Article is use for you.

<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d0d8aa53-b11d-2a10-aca2-ff2bd42a8692">MDM Data modelling do's and dont's</a>

Regards,

Vijay

Former Member
0 Kudos

Hi, Vijayasarathy

Thanks for sharing your thoughts.

Then another question for MDM experts arises - can we call those specific-to-system local attributes a 'Master Data'? If data attribute is system specific what's the point of managing it at enterprise level using MDM solution? The fact is there are no other systems that could gain from having this attribute available in MDM system since this data doesn't make sense for other systems.

Isn't cross-system enterprise level master data is the only type of data that should be designed in MDM repository?

Regards,

Vadim Kalabin

Former Member
0 Kudos

Hi Vadim,

Looking on the perspective on Load over MDM System there is no problem in having local or global attributes.

But thinking in terms of relevance as a master data now we have do decide based on the original scenario whether these local attributes can be considered as a Master Data. It depends on the Data and the process it is related with.

Eg.1.. Color Code can be local attribute but still can be a master data in case u want to integrate this with your portal.

2. In case of MDM is used as a Product Information Management system all local attributes need to master data.

So it entirely depends on the scenario that the relevance of the Master Data should be decided.

Hope this is a suitable response.

Expecting views of others.

Regards,

Vijay

Answers (0)