The Fourth Generation of MDM

Information Management Magazine, October 2007

Aaron Zornes

In meetings with the master data management (MDM) implementation teams, I have noted that the requirement for commercial MDM solutions to provide support for multiple types of master data (domains or entity types) is increasingly on the minds of business technologists at these large enterprises.

Specifically, the overarching concern is to avoiding "repaving the cow paths." This occurs when an IT group executes on a shortsighted strategy of mastering the master data in one given business area with a specific brand of MDM solution and then discovers that another division or line of business has chosen a different brand (and architecture) to solve their MDM issues. All too often, these different product-specific MDM solutions do not offer the capability of integrating master data across the great divide between party master data (customers, suppliers, employees) and product.

Clearly, enterprise MDM is a major IT initiative. Most enterprises and solutions vendors are finding near-term success with the single-faceted approach inherent with the third generation of MDM solutions. Increasingly, however, these same enterprises are determining that this myopic strategy of focusing solely on a single data domain and usage style is detrimental to the longer-term business strategy of integrating supply, demand and information chains across both product intra- and extra-enterprise boundaries. Coming to market are multientity MDM solutions, which are characterized as the fourth generation of MDM solutions.

Some requirements for such capabilities are provided in an industry roadmap which highlights the necessary planning assumptions, including (see Figure 1):

• Service-oriented architecture (SOA)-based MDM with multientity support is desired to manage master data domains that have significant impact on (and span across) the enterprises' most important business processes - compliance, cross-sell/up-sell and customer service.
• MDM is increasingly concerned with the notion of "multiples" - multiple data domains, the multiple relationships among them and the multiple usage styles.
• Most vendors approach MDM from either specific usage/domain pairing or broad tool - e.g., a rudimentary data model and set of tools for data quality, workflow, etc.- to build out the enterprise's own MDM infrastructure.

Figure 1: Myopic versus Strategic MDM

The value of multientity MDM can be intuitively recognized in a range of business initiatives - from short-term fixes to a narrow set of problems such as capturing customer privacy preferences across product lines to long-term enterprise-wide initiatives to delivering infrastructure agility by embracing SOA.

To help IT organizations and their business partners focus on the more desirable, longer-term MDM strategy, vital issues include:

• What is multientity MDM?
• Why is multientity MDM considered evolutionary while domain-specific MDM data marts are viewed as myopic?
• When will multientity MDM graduate from "early adopter IT project" to Global 5000 strategic business initiative?
• Which use cases are most amenable to benefit from multientity MDM?
• How does an organization plan for multientity MDM deployment?

During the last year, MDM solutions have matured from early adopter IT projects to become Global 5000 business strategies. The industry consensus is that "multientity MDM" is a software solution to concurrently manage multiple, diverse master data domains across intra- and extra-enterprise business processes. By centralizing the most critical master data to a single trusted source and managing this within the context of governance-driven data lifecycle, multientity MDM provides flexible business process integration across multiple data domains and usage types. Multientity MDM solutions deliver complex and collaborative business processes, such as identifying the most valuable customers, introducing new products rapidly, crafting new product bundles more quickly and managing threat and fraud risk more effectively.

Global 5000 businesses are rapidly ramping up plans to consolidate master data into data hubs using a combination of off-the-shelf data hubs, enterprise application integration, enterprise information integration, data quality toolkits and even custom-built IT projects. The current commercial off-the-shelf solutions available to enterprises are commonly characterized as third-generation solutions.

What are the vital signs of a third-generation CDI-MDM solution? In my experience, "Type A" MDM project leadership within very large-scale IT organizations recommends these five "DNA markers" as good indicators:

• SOA/shared services architecture evolving to process hubs;
• Sophisticated hierarchy management;
• High-performance identity management;
• Data governance-ready framework; and
• Registry, persisted and hybrid architecture flexibility.

Why multientity MDM? Why now? During 2007-2008, party and product data interdependencies will quickly broaden MDM requirements across data domains and the relationships among them - i.e., from customer to product to vendor. Figure 2 provides an overview of the attributes that are commonly shared between party entity and product entity. Currently, most MDM solutions vendors are focused on one or the other major entity - hence my use of the descriptive term conundrum to describe this riddle.

Figure 2: The Party:Product Conundrum

Most vendors approach MDM from either a specific usage/domain pairing or a broad MDM tool. Currently, the megavendors, for the most part, offer one center of gravity or the other. For example, SAP offers a product-centric MDM solution with its customer model being the product-centric view of business partner rather than the pure-play B2B customer. Oracle, on the other hand, has a native product information management  data hub that does not relate well to its counterpart, customer data hub, and also has from its Siebel acquisition a universal product manager that is a B2C customer-centric view of product as seen from the Siebel Universal Customer Master solution.

IBM has taken the bold step of integrating both of its MDM acquisitions (DWL and Trigo) such that the data models, the SOA services and underlying middleware all share a common stack that enables both party and product to reside coequally.

Additionally, the future MDM landscape will be influenced by multiple data domains; multiple relationships; multiple usage styles - analytical, operational and collaborative; as well as linkage between operational data domains using collaborative or analytical MDM.

Page 1 of 2.