|
Industry analyst firm IDC is predicting the master data management (MDM) 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 (SOA), 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 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, 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.
|
