The introduction of master data management (MDM) into the IT mix of data integration solutions came without much fanfare and hoopla, yet this form of integrated data greatly impacts the other two well-established IT environments – business intelligence (BI) and day-to-day business transactional (BTx) systems – and their architectures.

Unless you address this impact while implementing master data management, and examine its effects on your other environments, you may not maximize its benefits.

This article first defines an MDM environment and then describes how it should interact with the BI and BTx environments in an ideal world.

MDM is an Environment – Not Just a Database
Last year, I had the privilege of researching and investigating master data management with Colin White. The effort resulted in our research paper, Master Data Management: Creating a Single View of the Business, published in September 2006. Many of the ideas in this article are more fully described in that paper. We define a mature, enterprise-wide MDM environment as:

A set of disciplines, applications and technologies for harmonizing and managing the system of record and system of entry for the data and metadata associated with the key business entities of an organization.

Key business entities are defined as reference data about an organization’s core business entities (see Figure 1). The business entities include people (customers, employees, suppliers, etc.), places (locations and geographic points of interest), things (products, finances, etc.) and other key pieces of reference data of interest to the enterprise.

Master data management is more than just a hub or database of reference data. To truly manage master data, you need:

1. A coordinated set of applications,
2. Data integration services,
3. The corresponding master data metadata, and
4. The store of master data.

Figure 1 shows these four components working to create the full MDM environment.

Each component has a definitive role:

• MDM applications manage and publish master data and metadata.
• The master data store (MDS) contains consolidated master data.
• The master metadata store (MMS) contains the master data business model and master data rules and definitions.
• The master data business model documents master data entities, attributes, relationships and their business meaning.
• The set of master data integration (MDI) services consolidates, federates and propagates master data.

Figure 1: MDM Environment Components

Often, the MDM environment starts off as a tactical extension of a BTx or BI project. While this may have a short-term impact, it does not yield the full benefit available from a more strategic view of MDM. It can lead to partial implementations or, worse, redundant implementations – multiple and potentially redundant stores or “hubs” of master data (customer, product, locations, etc.) sprinkled across various areas of the enterprise. This situation is hardly the ideal of managing a single set of consistent, reliable master data available for both BI and BTx environments. Colin and I concluded, therefore, that:

To be successful, a strategic MDM initiative should be approached as an independent enterprise-level project with strong executive backing. An MDM system should act as an intelligent source of master data that drives other IT systems. It should not simply consist of a set of adjunct IT applications that gather and integrate existing master data to overcome the problems caused by dispersed master data management.

Having established the need for an MDM environment, let’s examine its impact on BI and BTx.

Keep it Simple!
The first thing we realize when we create an MDM environment – that is, an environment that separates the storage and maintenance of master data from both the BI and BTx environments – is that our BI and BTx environments become vastly simpler to design, implement and sustain. Think about it – how much of your efforts at data integration come from the need to create usable, current and historical master data? I know from experience that an MDM store would have made my life easier. If I just had to concentrate on integrating only the transactional data coming in from the various operational sources, my designs, processes and storage procedures would have been much easier and less complex. Sure, I still would have to figure out how to interface with the MDM store and ensure that I matched the right master data with the right transactional data, but the heavy lifting of master data integration would have already been done!

The same is true on the BTx side of the house. If operational systems had access to the MDM store, rather than managing and storing master data uniquely (and redundantly) in their own databases, they too would be simpler in design and implementation. The trick again is to ensure that each system is properly interfaced with the appropriate master data. Again, this is not trivial, but it’s certainly easier than all the interfacing currently going on between all BTx systems or the multiple and inconsistent master data “management” going on today in most BTx systems.

Figure 2 shows how these three environments – MDM, BI and BTx – must interface with each other and that these interfaces must ensure that the data flows into and out of each environment with ease.

Figure 2: Interactions Between MDM, BI and BTX Environments

Rethinking the Three IT Environments
The key to success with these three environments lies in the recognition that all three are enterprise-enabled. We have seen over the years that implementing BI or BTx environments in a parochial or silo fashion leads to a fractured, less-than-optimal situation. The grand and glorious benefits of a fully integrated and accessible environment are completely undermined. So it is with an MDM environment. Master data management must also be viewed from the beginning as an enterprise initiative with all the business and IT backing and support needed for such an undertaking.

In terms of the impact of the MDM environment on your BI environment, the MDM store can be used to supply not only relationally designed master data for your data warehouse, but also to supply conformed dimensional data for multidimensional analyses performed in the marts. The master data history in the MD store may also be used to restate BI results to obtain valid historical comparisons. An example from our research paper is the ability to compare July 2006 sales with July 2005 sales using the sales territories that existed in July 2005, even though the sales territories were changed in January 2006. This capability is particularly useful for financial reporting. In addition, enterprise MDM also provides the ability to map master data changes against data warehouse information to predict the impact of those changes on business operations and performance.

In terms of the impact of an MDM environment on the BTx one, you only need to understand the difference between the system of record (SOR) and the system of entry (SOE) for master data to understand enterprise MDM’s impact upon the BTx systems. The SOR is the application system responsible for publishing master data and metadata and ensuring its accuracy. The SOE is the application system responsible for creating and maintaining master data and its associated metadata. In a fully complaint MDM system, the SOR and SOE are the same system. Exceptions to full MDM compliance may always occur, but they must be agreed upon and documented by IT and business users.

Migrating the system of entry from the BTx systems to the MDM system occurs as both a cultural and technical challenge. The technical challenge is to ensure that this transition is smooth in terms of the switchover from operational system to MDM application. As more and more of the system of entry is converted to the MDM environment, each BTx system with entry capability for that data must either be altered to eliminate potential dual entry of that data or redirected to the MDM application for entry and update capability. If it is not possible to migrate a system of record to the MDM system, then facilities are required to blend the external master data into the MDM system so that its system of record is kept current. These changes can be significant to the BTx environment but may be accomplished in small iterations.

Cultural Hurdles
The cultural hurdles include the aforementioned executive support from both IT and the business. In addition though, there is the large hurdle of gaining acceptance for a single store of master data. Who owns it, who defines what the entities mean, how are changes to existing definitions and relationships managed? These are all questions that must be answered to the satisfaction of the business before the MDM environment will be culturally accepted. Another cultural hurdle is the funding for the initiative. An MDM environment is not created in a single project – it will take many projects and perhaps several years to get it fully implemented, and the business must sustain the funding to see the initiative to its final state.

If you’ve already started your MDM initiative as a tactical, line-of-business, master data registry or hub, the good news is that enterprise MDM can evolve from that point to one where MDM is better leveraged, provided an enterprise MDM plan is developed to support this evolution.

SOURCE: The Three Environments of IT