Comments on: Generic MDM message starts to sink in http://andyonsoftware.com/2007/04/generic-mdm-message-starts-to-sink-in/ Andy Hayler, founder of Kalido and The Information Difference, gives his views on the enterprise software market. Issues covered include data warehousing, master data management, business intelligence and data quality. Fri, 12 Aug 2011 09:22:13 +0200 http://wordpress.org/?v=2.8.4 hourly 1 By: admin http://andyonsoftware.com/2007/04/generic-mdm-message-starts-to-sink-in/comment-page-1/#comment-37866 admin Tue, 21 Aug 2007 22:05:13 +0000 http://andyonsoftware.com/2007/04/generic-mdm-message-starts-to-sink-in/#comment-37866 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. 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.

]]> By: Shiva http://andyonsoftware.com/2007/04/generic-mdm-message-starts-to-sink-in/comment-page-1/#comment-37835 Shiva Tue, 21 Aug 2007 08:23:24 +0000 http://andyonsoftware.com/2007/04/generic-mdm-message-starts-to-sink-in/#comment-37835 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 Shiva 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
Shiva

]]>