Generic MDM message starts to sink in

One thing I have been banging on about for a long time is how the MDM industry needs to move aways from its roots in CDI hubs and PIM if it is to address the needs of large enterprises on any scale. It seems obvious to me that if you end up with one specialised hub for each type of master data then you quickly descend into architectural anarchy. You have the various ERP systems, and are then going to add a customer hub, a product hub (different vendor) and then are going to notice that there are other important master data types that need managing, like financial data, assets, people data, brand information etc. Are hubs going to spring up to support each one? That way madness lies.

If we are to sort out master data properly then we need to isolate it in a master data repository, separate from a data warehouse and from ERP, which can manage and maintain all master data for the enterprise. This hub needs to be able to handle all data types and keep track of where versions of master data are, even if it is not the only place the master data physically resides. It at least needs to know where the copies of master data live, or else we are back in master data anarchy. I have been amazed at how few vendors (and customers) seem to have picked up on this obvious point. In their latest press release Siperian demonstrates that it, at least, has figured it out. The release itself contains the amusing claim that Siperian is the only MDM product that can do this: “the only operational hub capable of managing hundreds of different types of master data entities” which will come as news to, for example, BP Lubes, who are using Kalido MDM to manage 350 different types of master data and have been for three years. However, despite the over-egging on the marketing, at least Siperian seems to understand the problem, which is more than can be said for a lot of its competitors.

2 thoughts on “Generic MDM message starts to sink in”

  1. It is an interesting case. The master data is partitioned but not in the way you might expect. The application is a combined MDM and data warehouse application and the instances are deployed in a “federation” of Kalido instances, one per country or group of countries. In fact all the master data types are stored in a single repository, but one per country or country grouping. In practice as this is a B2B business it means that the volume of master data in not particularly large. Kalido was designed to be deployed in this fashion, in the warehouse context with summary data feeding up to the global level. You have the extra complication of dealing with the co-ordination of the instances, but of course this approach dramatically cuts down on the amount of data stored in an individual instance, as detailed data e.g transactions for a warehouse, is only needed for a particular country. Only summaries (and master data) are fed up to the global level. This type of implementation can also be seen at Shell Oil Products and Unilever.

  2. Hi Andy,

    Thanks for the nice post.

    Does BP Lube host all the 350 different types of master data in a single global hub (likely very massive) or in a few different hubs? How were data querying concerns addressed in such cases?

    I have a query pertaining to designing such multi-domain hubs. With different data domains being represented by different object schemas (which are not all known up-front, when we start with the first data domain, say Product data), how would one design a database schema to facilitate smooth evolution? Is there a generic, database approach adopted in your case? Like maybe a large, but fixed number of columns of various datatypes, which are then cast against actual attribute labels using Metadata? Can you share your experiences in this aspect of multi-domain MDM?

    Thanks and best regards

Comments are closed.