For some time now, data has been moving around the enterprise at faster and faster speeds. Banks, retailers, communications companies, healthcare providers, and high-tech firms, etc. all have an urgent need to share data across business applications, end-users, and core systems. The emergence of new technologies, most notably message bus solutions, facilitates these new levels of data exchange, but this data sharing reveals other problems, namely different versions of the same data.
There are more constituents, more lines of business, and more business uses for customer data than ever before. But as quickly as solutions for data movement are introduced, problems with the data itself becomes more visible: two (or more) data fields that mean the same thing nevertheless look different and are interpreted very differently. This is true for established data types like “Social Security Number” that imply strict formatting rules, but also for data types like “Address” where the rules might be less rigorous. Ironically, the trend of master data management (MDM)—the automation of data reconciliation across and between systems for various types of reference data—was greeted heartily by business and IT executives who were still fundamentally change-averse. Yet, many didn’t know what to do or where to start.
MDM is not a new solution to an old problem, but rather a new solution to a new problem. Simply put, it’s a paradigm shift. The reasons for this are fundamental to what MDM is. The true value of any MDM solution is its ability to acquire, asynchronously or in real-time, enterprise data from heterogeneous systems and online stores where that data originates. Whereas many vendors rushed to hang the MDM shingle, or re-craft their marketing messages to retrofit their products into the MDM rubric, the best MDM solutions are demand-driven: that is they match and correct data as it’s used and, not to put too fine a point on it, they don’t touch the data if it’s not being used.
As data is used for different purposes in different ways by different constituencies it erodes to the point where it can become generally regarded as untrustworthy. Even direct-source system reports, usually considered more reliable, are difficult to interpret. And, as you add more source systems, ETL programmers need to assess the impact to their expanding collection of ETL jobs and modify them. Point-to-point code that worked before stops working. This becomes even more unwieldy when you begin to consider subscribing to third-party data.
Bad Data, Bad Business
A sad turning point happens when mistrust of the data becomes part of the company’s culture. Following the inevitable pressure from business colleagues, CIOs eventually come around to the idea of going to “Plan B” and fixing the data “once and for all.” CIOs generally try to resist “Plan Bs” because they almost always involve disruptive technology. So, the search begins for a solution that needs to be flexible, authoritative and permanent. Yet because existing systems and users still needed data from the company’s data warehouse, CRM and EII environments, any solution needs to cause minimal system or business disruption.
Mindful of these requirements, the CIOs take a hard look at MDM for a single point of reference for data matching, integration and two-way propagation. A new MDM hub prevents “one off”, custom solutions for every new system linkage. It also eases the burden of having to propagate data from new sources and support different integration rules within and between operational systems.
With “Plan B,” the MDM hub assumes the role of a data reference system. Systems in need of data call the MDM hub for the reference record, and then retrieve the actual data. In tandem, you have the continued propagation of data to and from different systems. In this way, companies finally have access to authoritative versions of data for a range of applications while avoiding drastic, disruptive change.