I frequently describe MDM as subject area data integration. The whole point of mastering and managing data is to simplify data sharing, since confusion only occurs when you have two or more instances of data and it doesn’t match. It’s important to realize that mastering data isn’t really necessary if you only have a single system that contains one copy of data. After all, how much confusion or misunderstanding can occur when there’s only one copy of data? The challenge in making data more usable and easy to understand exists because most companies have multiple application systems each with their own copy of data (and their own “version of truth”). MDM’s promise is to deliver a single view of subject area data. In our book on Customer Data Integration (CDI), Jill Dyche and I defined MDM as:
“The set of disciplines and methods to ensure the currency, meaning, and quality of a company’s reference data that is shared across various systems and organizations.”
As companies have grown, so to have the number of systems that require access to each other’s data. This is why data integration has become one of the largest custom development activities undertaken within an IT organization. It’s rare that all systems (and their developers) integrate data the same way. While there may be rigor within an individual application or system, it’s highly unlikely that all systems manipulate an individual subject area in a consistent fashion. This lack of integrity and consistency becomes visible when information on two different systems conflict. MDM isn’t a silver bullet to address this problem. It is a method to address data problems one subject area at a time.
The reason for establishing a boundary around subject area is because the complexity, rules, and usage of data within most organization tend to differ by subject area. Examples of subject areas include customer, product, and supplier. There can be literally dozens if not hundreds subject areas within any given company.
Do you need to master every subject area? Probably not. MDM projects focus on subject areas that suffer the most from inaccuracies, mistakes, and misunderstandings, for instance, customers with inaccurate identification numbers, products missing descriptive information, or an employee with an inaccurate start date. The idea behind master data management is to establish rules, guidelines, and rigor for subject areas data.
The rules associated with identifying a customer are typically well defined within a company. The rules associated with adding a new product to the sales catalog are also well defined. The thing to keep in mind is that the rules associated with product will have nothing to do with customers. Additionally, most companies have rules that limit what customer data can be modified. They also have rules that restrict how product information can be manipulated.. The idea behind MDM is to manage these rules and methods in a manner where all application systems manipulate reference data in a consistent way.
Implementing MDM isn’t just about building and deploying a server that contains the “master list” of reference data; that’s the easy part. MDM’s real challenge is integrating the functionality into the multitude of application systems that exist within a company. The idea is that when a new customer is added, all systems are aware of the change and have equal access to that data.
For instance, one of the most universal challenges in business today is managing a customer’s marketing preferences. When a customer asks to opt out of all marketing communications, it’s important that all systems are aware of this choice. Problems typically occur when a particular data element can be modified from multiple different locations (e.g., a web page, an 800 number, or even the US Postal Service). MDM provides the solution for ensuring that the master data is managed correctly and that all systems become aware of the change (and the new data) in a manner that supports the businesses needs.
I like how you decompose the problem and provide practical, "don't boil the ocean", guidance.
First I want to thank you and Jill for the outstanding content in your books. I read them on a regular basis. You could say I am a bit of a fan.
The title of this blog got my attention, and couldn't help myself to provide you a few lines of my own.
Although MDM stands for master data management, I guess you could actually manage all kinds of data; not only master data subjects but any data subject. So why do we need to manage data in the first place? I strongly believe it's the only way to assure that data is transformed into trustfull information. By allowing the business to manage it's own data, they are not only improving the integration of the data but also it's quality thru correction and enrichment. This results in hidden information (e.g. households, B2B, B2C or products bundles) coming to life. I guess what I am trying to say is that even with a single system, MDM makes sense. Maybe not for data integration purposes, but certainly for data quality improvement and making information never seen before available to the business and knowledge workers.
Regards, Kees