Master data management reminds me of the tale of the blind men and the elephant. The paraphrased story is that several blind men were led to an elephant and asked what it was. One each felt the elephant's head, eyes, ears, tusk, trunk, foot and tail. Naturally, the explanations of the elephant given from such different perspectives were quite different. So it is with MDM, which either is or can be any of a number of things in a given client situation and perspective.

One common starting point for MDM projects is the refrain of data quality, widely seen as a very important aspect of MDM. No matter how you architect MDM, if the data you deliver is lacking the necessary quality to achieve trust with the users and systems owners, your MDM efforts are basically worthless. Effective MDM achieves high quality for the data brought into its domain, and data quality cannot be ignored in MDM. To proceed with the elephant analogy, data quality is the feet of MDM because without it, MDM cannot make progress.

Other business cases for MDM begin with the necessity to support a new application that really needs to master a subject area. There may be a key application, like customer relationship management (for customer) or making your product catalog electronic (for product), that can either be the impetus or the immediate beneficiary of MDM. Well-done MDM here is really siphoning off some of the application budget, and piggybacking MDM on the application to provide it with master data - but doing it in a scalable fashion so that other applications can eventually benefit. Master data needs to be built for each application and, once you break it down, you may be surprised at the large percentage of the application that master data actually becomes. This approach to the new application should reduce its risk and accelerate its timelines. New applications are the metaphorical tail of MDM because one or the other is getting dragged along.

Applications that exist today may need to share master data, either for lowering the total cost of ownership in the management of that data or because it is important that they be on the same page. For example, you may want the CRM application and the point-of-sale application to use the same customer list, even though, beyond the core attributes, each may be interested in a different set of attributes. Imagine the disconnect with marketing and cross-sell promotions if these two apps are out of sync. Existing applications are the tusk of MDM because they provide sharp ROI, which protects the entire organization.

Regardless of where the data model exists in the environment, the most valuable aspect of MDM to an organization may be a data model that contains a superset of attributes about the subject area, kept at a fine grain of detail, adhering to good modeling standards, well-named and supported by metadata. The model ends up in the most leveragable place in the environment - the MDM hub. The model is the eyes of MDM because it has to look out for and incorporate enterprise attributes.

Processes that generate and maintain good master data may not exist in an organization today. The act of instituting those processes through a particular workflow may be the most interesting element of MDM. Without master data, there is no MDM. Processes generate master data. Sometimes incorporating what may be passing for master data today in an organization into MDM is unacceptable to either short or long-term objectives. The processes are the trunk of MDM because it is what is used to bring in the data.

Building those processes to endure should not be done without appropriate organizational buy-in and contribution. Some will see MDM as data governance - setting the policies and procedures that support the build and maintenance of the master data, as well as some of the more detailed tasks involved in the MDM rollout. Data governance is the head of MDM because that is where the brainpower is applied.

Finally, MDM is sometimes instituted as a means to meet compliance requirements. While addressing data quality in the form of process traceability and proper identification of customers, patients, etc., these regulations inevitably involve high measures of security. MDM's ears are continually listening for security violations.

Certainly, any of the parts of MDM can yield great value including improved data quality, new applications, putting existing applications onto common data, an enterprise-oriented data model, processes to generate master data, governance buy-in and data security. A focus on one area perhaps may be the best way to get started. However, the most value is going to come from all of them taken in the aggregate over time.

Even in its relative infancy, MDM is already confusing due to the variety of perspectives applied to its initial calling in an organization. However, all the perspectives have value. Just be sure not to stop at these labels. At the end of the day, whether you call it MDM, data governance, data quality or data modeling, it can and should be called good business.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access