Industry analyst firm IDC is predicting the master data management market to grow to $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 each 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.
Despite the flurry of activity, no one is talking about MDM in the same way, 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, is a single platform even necessary?
After all, while MDM has come to fore 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 an understanding of what constitutes master data. Master data includes the critical data entities and their common attributes which 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 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 to be tied to customer data but associated with multiple accounts over time. While these debates may rage on for some time, it is important not to be stymied by them and begin your MDM journey with a confirmed master data domain, such as customer data.
MDM: system of record or system of reference?
What many organizations fail to realize is that MDM is fundamentally 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, an employee or a supplier. Once validated it then serves this data for consumption to downstream business applications and upstream source systems.
In contrast, the 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 where 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 kinds of usage 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.
These master data domains differ greatly. For instance, customer master data often originates from multiple sources, including several from outside 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 internally and shared externally among suppliers. The characteristics of product master data – such as 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 workflows required to manage changes to master data, the ownership of product master data is distributed among a handful of subject matter experts.
It is being debated whether any mega-vendor today can handle these differing requirements in a single integrated MDM platform. But here is the more pertinent question to ask: 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 move forward with MDM is to initially deploy one master data domain for a specific business need, and then extend 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, doctor or hospital data for a pharmaceutical company, counterparty reference data in institutional banking or product data in retail.
By starting with one data domain, companies are able to 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 a MDM initiative.
However, the key to this approach is to select an adaptive MDM platform that can easily be extended to different data domains over time to meet future requirements. An adaptive MDM platform should not only support SOA and allow you to coexist with existing data hubs, data sources and the larger application platforms, but also allow you to evolve the architectural style over time across the organization to implement a comprehensive master data management strategy.
Remember MDM is a strategic process and while mega-vendors are vying for dominance, each master data domain presents unique challenges. An adaptive approach is necessary to meet these challenges and enable you to start down the path to MDM without compromising your ability to evolve towards an enterprise-wide master data management platform.