The Myth of a Single Vendor Platform

Master data management (MDM) is a new approach to an old problem in companies: Merge all of the disparate, often conflicting and redundant records on customers and transactions into one authenticated master file.

Industry analyst firm IDC is predicting the master data management market to grow to US$10.4 billion by the year 2009, with a compound annual growth rate of 13.8 percent. Other analyst firms, such as Gartner and Forrester Research, claim that MDM provides significant business benefits and is a critical foundation for managing enterprise information assets.

Not surprisingly, the market hype from the mega-vendor triad (IBM, SAP and Oracle) has been deafening, as each one attempts to position its single enterprise-wide platform as a complete solution to a company’s MDM strategy.

Inciting MDM Conversations

Despite the flurry of activity, no one is talking about MDM consistently and there is no consensus on crucial questions that CIOs and executive management teams want to address.

More specifically, businesses need to answer the following questions before getting started:

• What are all the master data domains?
• Where is the business value of MDM?
• Should the MDM journey begin with operational or analytical systems or both?
• Can a single vendor’s MDM platform really serve the varied requirements of all the data domains?
• In a world of service-oriented architecture (SOA), is a single platform even necessary?

While MDM has come to the forefront as a critical area of data management practice with different data domains, the MDM requirements have not yet coalesced into a coherent market.

Master Data: Eye of the Beholder?

Starting down the path to MDM begins with understanding that master data includes the critical data entities and their common attributes that qualify a company’s business events.

Customer and product are the two most common master data domains. Invariably, firms begin with managing one domain (say, the customer data) and soon encounter the need to manage the other master data (such as products associated with a customer). There is little controversy that customer, product, location, employee, asset and financial entities are master data domains.

However, there is often a debate whether or not certain data domains need to be treated as master data. For instance, should pricing be master data? What about contracts? Whether structured or unstructured, master data is best understood in the context of business processes. For example, in an order-to-cash process, a contract may be deemed as master data that is to be tied to customer data but associated with multiple accounts over time.

While these debates may continue, it is important not to be stymied by them. Begin your MDM journey with a confirmed master data domain, such as customer data.

System of Record or System of Reference?

What many organizations fail to realize is that, fundamentally, MDM is a governance process. This means that the organization’s critical data is consolidated among multiple sources; is often validated to ensure the data is correct, consistent, and complete; and is then shared for consumption within the context of applications, business processes, and users.

Through this process, a MDM solution may need to support two kinds of usage: a system of record or a system of reference.

The former is an authoritative, central source that originates and validates a new customer, employee or supplier. Once validated, the system serves this data for consumption to downstream business applications and upstream source systems.

In contrast, a system of reference is an authoritative master data source validated as a reference for certain limited downstream processes or applications but is not a system for origination. For example, an item master may be a product system of record in which all new product items are created, but an entirely different product master hub may serve as the system of reference for contract hierarchies or pricing processes.

Therefore, a core MDM governance requirement is to support these two usage types and be able to harmonize data across these different hubs, often in heterogeneous IT environments.

Is a Single Vendor Platform Necessary?

At the organizational level, MDM is a cohesive strategy for managing all master data domains, whether customer, product, employee, asset or financial.

Each of these master data domains differ greatly. For instance, customer master data often originates from multiple sources, often including sources from outside of the company. The customer master data is often structured and well understood while typically following a “business party” model. Data reconciliation and synchronization are critical issues when validating customer master data. The ownership for customer master data is distributed among multiple customer facing personnel and data governance may be centralized or globally distributed.

On the other hand, product master data is usually generated in-house and shared externally among suppliers. The characteristics of product master data — such as what one finds in a product catalog or an item master — are both structured and unstructured and semantically unclear while requiring a “hierarchical” data model.

While governance is centralized with work flows required to manage changes to master data, the ownership of product master data is distributed among a handful of subject-matter experts.

One issue that invariably arises: Can any mega-vendor today handle these differing requirements in a single integrated MDM platform?

The more pertinent question: Is centralizing on a single MDM vendor even necessary? If the SOA promises of mega-vendors are indeed true, then why not select different best-of-breed solutions that work together to deliver the most suitable solution?

Shouldn’t each MDM solution leverage your past investments in data integration infrastructure, legacy data hubs and external data sources?

If not, isn’t relying exclusively on single mega-vendor platform an expensive path to mega-vendor “lock-in”?

Perhaps the most critical question to ask is, where is your organization most likely to derive business value from a MDM platform?

The Path Forward: Adaptive Master Data Management

Many companies are finding that the easiest route to follow with MDM is to initially deploy one master data domain for a specific business need, and then extend that to other data domains over time — which data domain to start with will differ by industry.

For example, it may be customer data in high-tech, hospital data for a pharmaceutical company, counterparty reference data in institutional banking or product data in a retail market.

By starting out working with one data domain, companies can achieve immediate ROI in an identified area, typically in less than six months time. Further, by starting small with an identified data domain related to a critical business process improvement, you can kick-start an MDM initiative.

However, the key to this approach is to select an adaptive MDM platform that can be easily extended to different data domains over time in order to meet future requirements.

An adaptive MDM platform should not only support SOA and allow your information to coexist with existing data hubs, data sources, and the larger application platforms; but also, it should allow you to evolve the architectural style across the organization to implement a comprehensive master data management strategy.

Remember, MDM is a strategic process and although mega-vendors are vying for dominance, each master data domain presents unique challenges.

An adaptive approach is necessary to meet these challenges, as well as implement MDM without compromising your ability to evolve toward an enterprise-wide MDM platform.