We have worked on a number of projects for organizations that have begun to design and build master data management systems to operate as consolidation platforms for unique identification of a set of master domains, even though they might not have effectively thought through how that master data asset was to be used. So the question arises: given an MDM system that is evolving and maturing, how do you engineer a migration plan to incorporate the set of master data services into the existing information and application infrastructure?

Let’s look at an example: integrating an existing data warehouse with a set of business intelligence applications with an MDM system. From a practical standpoint, the horse has already left the barn – the data warehouse is already in production, while the development of the MDM system is already underway, and that means that it is too late to drive the MDM requirements from square one based on the data warehouse usage scenarios. However, there are still opportunities to influence the continued MDM development in relation to meeting the business needs of the data warehouse users.

We are able to consider technical requirements from the data warehouse and recommend adjustments to the MDM development plan by considering what needs to be done to ensure observance of the end-user business expectations. Essentially the requirements for integrating a data warehouse with a master data repository is based on assessing the data dependencies relating touch points in the data warehouse and those data entities and elements that should be managed within that master data repository. This suggests potential requirements for managing consistency between the data warehouse and the MDM repository in a bi-directional manner: considering when the master data repository feeds the data warehouse while determining when interactions with the data warehouse impose updates to the repository. Over the next set of posts we’ll look at some of these requirements in more detail.