Executive Summary

Let’s assume that we have passed the critical initial stages of developing a master data management (MDM) program — we have clarified the business needs, assessed the information architectures, and profiled available data sets to identify candidate sources for master data objects. Having used our tools and techniques to determine our master data types and determine where master data is managed across organization applications, we are now at a point when we must consider bringing the data together into a managed environment.

At this point, we again we face a challenge. Despite the fact that we have been able to identify sources of master data, the underlying formats, structures, and content are undoubtedly different. Yet to accommodate the conceptual master repository, all of the data in these different formats and structures needs to be consolidated into a centralized resource that can both accommodate those differences and, in turn, feed back into those different representations. That implies the following:

1. There must be a consolidated master representation model to act as the core repository
2. Processes for capturing data, resolving the variant references into a single set, selecting the “best” record, and transforming the data into the repository model must be defined
3. Processes must be created to enable the publication and sharing of master data back to the participating applications

Accomplishing these goals is dependent on two things: creating a suitable and extensible model for the master repository, and providing the management layer that can finesse the issue of legacy model differences.

To meet the objectives of the MDM initiative, the data from participating business applications will eventually be extracted, transformed, and consolidated within a master data object model. Once the master data repository is populated, depending on the architectural style selected for the MDM implementation, there will be varying amounts of coordinated interaction between the applications and the master repository — either directly, or indirectly through the integration process flow.