The success of any implementation is dependent on three important aspects - people, processes and technology. Of these three factors, technology is driven by the people and process. Life would be very simple if all problems were just technical, but that’s not the real world. It’s easy to solve the technical issues, but it’s very difficult to resolve issues related to people. The same goes for processes. In today’s world, processes have more political influence than a delivery. Like any implementation, the successful deployment of master data management ensures that all three factors are used effectively as an enterprise asset.

Management of master data is not new. People have used some form of this concept in their own way from the time they started managing their data. So then, what is a precise definition of MDM? MDM is a combination of processes and technologies that will help enterprise manage their data flow, data integrity and data synchronization in a better way. This definition emphasizes enforcing policies and standards to the core data at an enterprise level.

Because of the various interpretations of MDM, some common misconceptions have developed.

Misconception 1: MDM is like data warehousing

MDM is all about using information as a service. MDM is a set of disciplines and methods which are used to ensure the accuracy, completeness, meaning, timeliness, consistencies and quality of a company’s reference data across enterprise and various subject areas.

The architecture of MDM by itself is divided into two major classes. Depending on the goal being addressed, it is categorized mainly as operation or analytical.

As the name suggests, operational MDM handles the master data from a front office perspective, whereas the analytical MDM is more for the predictive analytics, historical information analysis and forecasting. The complex data hierarchies and their relationships can be maintained more efficiently in MDM rather than a data warehouse.

An MDM architecture often has the nature of a centralized hub,and because of this, people make comparisons to the data warehouses. At the highest level, both MDM and data warehousing aim to offer clean and meaningful information to the enterprise. But other than this, these two are built for different purposes and for different audiences. MDM is more like a service and operates more on the operational data integration aspects, whereas data warehouses are built to support business intelligence applications by mining patterns and trends more with the available historic information.

Misconception 2: MDM is a technology/infrastructure initiative

MDM is more like a “discipline” than a typical IT initiative. The key to success for an MDM implementation is to have all the stakeholders on the same page; it seldom depends on the tool being offered in market or a homegrown approach. If we break down the MDM initiative into six categories as defined below, we would see interestingly that technology gets the last position. There are many other aspects to be taken care of before even getting to the technology piece of assessment and/or work. The building blocks of MDM initiatives adopted in industry are in the below order:

1. Vision: Why is MDM needed for the given enterprise, and what does MDM look like for the enterprise? Who owns it? These why, what and who questions are very important from a business case perspective, and will help stakeholders keep a close watch on whether or not the initiative is meeting the goals.

2. Strategy: This is the “how” aspect of the initiative. The strategy should address two key things:

a.The MDM vision of the enterprise is mapped correctly with the factors like commercials, profit-revenue and regulatory compliance, etc.

b.What is in scope and what is not in scope for different verticals and future phases. What is not in scope is as important to define as what is in scope because each vertical and business area will have different needs to be catered to. The expectations and priorities will be different. Hence this activity will put the prioritization in place.

3. Metrics: The only measurable link between the MDM initiative and the business value is metrics. These measurable objectives come from the MDM strategy. If you have defined, for example, profit-revenue in strategy, you can measure it with key performance indicators using relevant metrics. These metrics should be driven and owned by business and not IT because only business can fully identify and measure the value of the initiative.

4. Governance: This is the most important aspect for the success of an MDM initiative. The formal process to implement governance would be to have stewardship, which would force the structure to put map roles and responsibilities with the accountability and authority in the MDM initiative. The ideal approach would be the leadership coming from the business side, and IT should be facilitating the initiative. This should include multiple subject areas like security, change management, training and communication. The basic factors to be addressed include who creates, who manages, who owns and who consumes the data.

5. Processes: Because the whole initiative revolves around the management of the master data, it becomes even more important that processes are defined and followed for all aspects of governance as well. All the “who” questions in the governance plan should have a “how” and a process flow to achieve the goals. This would involve publishing the data including a process to identify the data quality issues.

6. Technology: This is a broad world in itself. The technology assessment should start with the big picture in mind. This includes planning an architecture and infrastructure for data integration, data storage, middleware, publishing, user interface, and integration with future applications and systems. This also includes the selection and methodology to deliver this solution, which requires making key decisions such as whether to build the capability or to invest in a market-ready tool. This also includes getting on board with the right skills and resource matrix that will be making the delivery happen on the technology front.

Misconception 3: MDM should be treated as a data quality program

For MDM, there is no doubt that data quality is of the utmost importance and relevance. If a customer or a product cannot be identified unambiguously due to poor data quality, the purpose of building master data or reference data will be defeated. It’s very important to ensure that master data is timely, relevant, complete, valid, accurate and consistent through governance and quality initiatives.

Having said that, it should also be understood that the scope of MDM includes a data quality management program. Data quality is a must for successful implementation, but it’s just one of the success factors, not the sole one. There is a big difference between MDM and data quality management. A typical data quality program will have at least two major streams of work done extensively: data quality requirement analysis and data quality modeling.

When a program takes shape then it goes through all other program management aspects and challenges as well. Hence, it will not be appropriate to say that MDM is a data quality program. The goals, vision and success criteria for both these programs are quite different. They might share some of them, but still are two different independent programs.

Misconception 4: Assuming data governance is an “optional” architectural component

While every enterprise relies upon information to service and compete, maintaining information quality and consistency are challenges by itself. This is of higher relevance where enterprises are highly distributed and operating dispersed. Loosely coupled IT and business infrastructure can easily put the MDM initiative into a very challenging mode. Most data governance initiatives are driven by some kind of pressure. The most common ones are:

  1. Regulation compliances,
  2. Operational management,
  3. Information growth and complexity in dispersed environments,
  4. Better risk management,
  5. Improved accountability and
  6. Alignment with enterprise strategies.

The driving factor could be internal or external, but the simple fact is that data governance is not a luxury. If not defined and controlled from beginning, the decision-makers will not be able to base their decisions on information that would is accurate, timely and trustworthy.

Misconception 5: MDM should be treated like an application

MDM is a process, not a technological deliverable. One cannot assess the value of MDM with the application built to access or use it. Common terminology within the industry often classifies MDM as an application. If we track back to what a typical application means in IT, the definition would be: the technology used to perform a specific task or function for an end-user or for another application. An application’s success criteria would be to measure how user-friendly it is, how easy it is to navigate, how it looks and feels, etc. MDM success is not just about how easy its to use, but rather about what business value it is delivering.

The application is needed to view and modify the data entering and leaving the master data store, but that’s only catering to data access and not MDM.

Recent studies from prestigious research groups in the industry have revealed that best-in-class companies enjoy measurable, significant business benefits from MDM initiatives. Success stories have clearly stated their MDM initiatives were completed on-budget with better data usability and a better completion rate. All these things are connected with major architectural components like data governance and data quality. It might not be perfect yet, but the journey has begun.

The four most important attributes for MDM would be data accuracy, completeness, timeliness and consistency. MDM should always be an enterprise initiative; it should never be aimed at addressing only isolated problems. The best approach for successful MDM implementations would be proactive rather than reactive.

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