Business Intelligence Network - The Vision for BI and Beyond

A Phased Approach to Enterprise Master Data Management

Published: June 20, 2007

Enterprise master data management (MDM) should always be the objective of any long-term MDM plan, and the secret to implementing this plan is a phased and tactical approach.

An enterprise master data management (MDM) system should be the ultimate goal of organizations building a master data processing environment. For many companies, building such a system is a complex and multi-year effort. In fact, due to a combination of politics and the sheer complexity of their existing IT systems, many organizations may never fully achieve this goal. Nevertheless, enterprise MDM should always be the objective of any long-term MDM plan. The secret to implementing this plan, however, is a phased and tactical approach to enterprise MDM.

Enterprise MDM Architecture
Master data (MD) processing is typically viewed as consisting of a set of application systems (the systems of entry, or SOE) that modify a global master data store (the system of record, or SOR) based on master data maintenance requests from external users and applications. To discuss a phased approach to enterprise MDM, however, this perspective of master data processing must be expanded. A flexible enterprise MDM environment should consist of five distinct elements (see Figure 1):

• A global MD repository of MD and its associated metadata.
  
  
• A set of shared MD services that are used by applications to access and maintain the global MD repository. As the figure shows, these services cover a wide range of capabilities from master data analysis and modeling to master data security and integration.
  
  
• An interactive MD workbench that allows administrators and business users to analyze, design, maintain, and report on information in the global MD repository.
  
  
• Custom-built and/or packaged MD applications that use MD services to maintain the global MD repository.
  
  
• Business transaction (BTx) and business intelligence (BI) applications that employ native or service-oriented interfaces (provided by MD services) to consume, and possibly update, information in the global MD repository.

Figure 1: Enterprise MDM Components

When designing an MDM system, it is important to consider these five MD elements as key building blocks, and to separate the MD application processing from the storage of the MD, and from the shared MD services that assist MD processing. This architecture should also be taken into account when evaluating packaged vendor MDM solutions. If the package doesn’t clearly delineate these five processing elements, then its use will likely result in multiple MD silos.

A Phased Approach to MDM
Given that Figure 1 depicts the ideal enterprise MDM environment, how do organizations move to such an environment from where they are today? To be successful in such an endeavor, short-term tactical MD projects are required. Few organizations have the resources to move to a complete enterprise MDM environment in one step. Those that attempt it are likely to fail.

Figure 2 shows different approaches to MDM implementation. The actual approaches used and their sequence of implementation will depend on the business priorities of the organization, on budgets, on the capabilities of the existing IT infrastructure, and on the skills of the IT organization. The ultimate goal though is the architecture shown in Approach 5.

Figure 2: Master Data Management Implementation Approaches

Following is a brief overview of each of these approaches.

1. Consolidate MD in a data warehouse for analytical processing and/or for maintaining a historical SOR. This approach is often called analytical MDM and is one of the most common used by organizations today. As master data changes in business transaction applications (the systems of entry), the changes are consolidated in a data warehouse, which maintains a historical record of the master data. The historical master data in the warehouse reflects the MD system of record at different moments in time. As in any data warehousing environment, the historical master and transaction data in the warehouse can be used for BI analytical processing. The biggest issue with this approach is the complexity of maintaining a complete historical record of master data and master metadata changes. Techniques such as slowly changing dimensions are only a partial solution to this problem.
   
   
2. Synchronize MD across SOEs. This approach (which can be thought of as operational MDM) employs an integration hub to propagate master data changes between systems of entry to keep the master current across systems. This approach is only suitable when there are a small number of systems of entry. Larger systems become unmanageable because of business rule and master data conflicts between the systems.
   
   
3. Maintain a low-latency SOR in an operational data store. This approach uses an integration hub to propagate and consolidate master data changes in a low-latency operational data store (ODS). The ODS is used to present a near-current system of record to business applications and users.
   
   
4. Maintain an SOR in a master data store. This approach extends Approach 2 by maintaining a master data store in the integration hub. The hub’s master data store acts as the current system of record. The integration hub uses master data services to do tasks such as conflict resolution, and to reconcile and merge master data records. The master data store can also be used to propagate reconciled historical master data to a data warehouse. One technique used in some projects, as an interim step to a full hub-based master data store, is to create an identity registry in the hub that connects (using a master identifier) related master records in each of the systems of entry. This registry can be used to create a virtual master data system of record.
   
   
5. Migrate business transaction (BTx) SOEs to enterprise MDM. This approach extends Approach 4 by exposing master data services in the integration hub through documented interfaces. These interfaces enable existing business transaction applications to be modified to maintain master data in the hub, rather than in local data stores. The interfaces can also be used by new custom-built and packaged master data management applications to manage master data and master metadata in the hub. This approach also adds an MD workbench that allows administrators and business users to interact with the integration hub and its master data store. The workbench can be used to define, manipulate and report on master data and master metadata.

If you found this article helpful and would like to receive the latest insights each month from Colin White and other Network authors, please subscribe to the Business and Data Integration Newsletter.