The Current State of MDM

This will be a multi-part blog series as there is a lot to cover! Before we focus on the future of Master Data Management, it’s important to understand the current state of MDM. The real current state. The successes and failures. And more importantly, the ones that are neither success nor failure, but are in limbo. Understanding challenges that have prevented MDM from living up to its full promise is a great way to predict the future of what MDM needs to become. 

Let’s start with Current State # 1 – Operational MDM projects that are caught in no-man’s land. In this sort of project, MDM ingests data from operational systems like CRM and ERP, match data records, and provide master data back to operational systems and processes. There’s a specific type of operational MDM, usually called “Transactional MDM”, where MDM is actually the system of record for data, like customer data, and participates in operational transactions in real-time. This was a popular implementation style in financial services. The idea was to replace back office Customer Information Files with Customer MDM systems. Some of those implementations succeeded and still have MDM at the heart of their front and back office operational processes. But a great number of them are stuck in no-man’s land. Often, implementations leveraged existing batch data feeds to populate the MDM system. After amassing data, the idea was to turn on real-time consumption of master data. In financial services, many of these MDM deployments began in the 2000s. The MDM products used were deployed on-premises. Today, many of those products don’t have ongoing investment and product roadmaps. Most vendors have pivoted over to cloud MDM and have wound down their on-premise products. Others have curtailed investment and don’t have a cloud MDM product. And so, these organizations are caught in no-man’s land. 

Many companies have been left to determine what they should do with MDM. Some have simply decommissioned it. For projects that were feeding MDM far more than they were consuming it, this is a valid option. Others have taken the approach of decommissioning MDM and partially replacing some of its capabilities with a modern, cloud MDM alternative. Often, they are not looking to implement an operational MDM style, or specifically, a transaction hub. After regrouping, those companies have implemented MDM to match data to be consumed by other systems, often analytical ones such as data warehouses and lakes. And still, others decommissioned MDM and completely re-evaluated their need for master customer data, choosing to match data records as part of their data warehouse, or implementing Customer Data Platform (CDP) to provide a Customer 360 for marketing. 

What can we learn from this? What clues does it offer for the future of MDM? First lesson – many spent a lot of time feeding MDM, hoping to later consume that data. Sometimes the consumption never happened. Lesson – focus on consumption. MDM really needs to automate the ingestion and matching process to cut down the deployment time, and make it as easy as possible to start consuming master data. 

Second lesson – you don’t have to replace a legacy MDM system like-for-like. In fact, deconstructing MDM into its features and its use cases will reveal you may only need pieces of MDM. You may also find that the use cases for originally implementing MDM have changed, or are simply no longer relevant. You may be able to replace MDM by decommissioning it, and replacing pieces of its functionality to address currently relevant use cases. Most important – you don’t have to replace MDM with another MDM. 

This is the first part of a series on the current state of MDM, and then we’ll shift to focus on the future of MDM. Let’s start a dialogue about this. What are your thoughts on operational MDM? Migration to cloud MDM? Deconstructing what MDM was for, and then reconstructing what it needs to be in 2024? Leave your thoughts below in the comments!