The Data Power Struggle
Master Data Management is not a technical problem, instead its about power and control
Master data management (MDM) has acquired the unfortunate illusion of sounding more mysterious and complex than it really is. Strip away the diagrams, the consultant vocabulary and the technical mumbo jumbo talk of platforms, versions and features, and an MDM architecture is really a description of how much work the MDM hub actually does. Is it merely pointing to data held elsewhere? Does it match records? Does it keep a trusted copy? Does it correct data and send the corrections back? Or does it become the place where master data is created in the first place?
MDM exists because organisations rarely run on one clean set of data. As they grow by acquisition, project, department and workaround the data becomes more and more fragmented and disorganised. For example, a customer might appear in one system as a billing account, in another as a service record and in a third as a marketing prospect. A supplier, product, employee or location can suffer the same fate. The result is not necessarily chaos, but a level of ambiguity that drags businesses down. Master Data Management is a way of coping with this ambiguity.
In reality, MDM is a modern expression of a long standing problem, which is ‘how do you manage the consistency and integrity of the many data assets spread across your organisation?’ This data lives in systems such as ERP’s, SCM’s, CRM’s, BPM’s, ODS’s, data warehouses (and marts), legacy applications, and various home-grown applications. Each system creates and uses data that may partly, or sometimes almost entirely, overlap with data held in one or more of the other applications. Where you have the same customer, product or other core business data existing in multiple systems the challenge becomes keeping the data in sync. This is where MDM comes into the equation.
The objective of MDM can be therefore summarised as providing a consistent view of an organisations dispersed data and its associated definitions.
Quote taken from ‘Mastering Your Data’
The hub is central to any MDM architecture. Just as a real-world hub sits at the centre of an activity, an MDM hub sits at the centre of your master data world. But not all hubs are equal! There are a number of different styles of master data hub and each with their own advantages and trade-offs. Some styles leave the master data where it is and merely maintain links, some gather it into a hub for reporting, and some synchronise it back to the systems that use it.
1/ Virtual or External Reference styles
The lightest pattern is the virtual or external reference style. In this scenario the hub does not hold master data and does not claim to improve it. All it does is provide a reference point that enables you to be able to find, link or call data that remains in existing systems. There is no attempt to manage any issues with the data such as duplicate customers and difference in details across systems. It just tells you where all the customer data is for John Smith, regardless as to whether it’s all the same John Smith
This style of hub can be useful where disruption is unwelcome, ownership is contested or the immediate need is discoverability. Its limits are equally plain as whilst it can make fragmentation easier to navigate it doesn’t turn poor records into good ones.
2/ Registry style
The registry style of MDM hub is obsessed with identity. Master data stays in its original source system, but the hub adds matching, cleansing, identifiers and cross-references so that records can be recognised across the estate. It would for example establish that three similar looking customer records are, in fact, the same customer or that they are in fact two completely separate customers with similar details. So in essence the hub is acting as a central index of all your master data.
The benefit is that it creates a joined up view without demanding immediate reform of every source application. The drawback is that whilst it will identify issues and disagreements with the data it isn’t going to resolve them. Registry is therefore strong on recognition, weaker on correction.
3/ Consolidation style
Consolidation style which also used to be called Analytical MDM goes a step further than the registry. It draws your master data from several sources into a central hub, standardises it, cleanses it and presents a trusted view.
Whilst great for reporting, analytics, compliance and management information in general as a consolidation MDM hub will improve, fix and generally organise your master data into ‘consolidated’ records. But the original master data will stay as it was in the originating system. In effect this is just a sticking plaster over the data. It will look great but underneath its still shit.
4/ Reconciliation
The reconciliation styles of MDM hub lives in a world between full blown MDM hub, the registry and a consolidation style. The hub stores more than just identifiers for example it will applies rules, stewardship decisions, improve the quality of the data and may publish changes back to source systems. It is no longer merely observing the enterprise; it is beginning to intervene. It can be quite difficulty to govern as decisions need to be made about which system has authority and what happens when data collides, ie we have multiple versions of the same data.
5/ Transaction style
At last, we have come to the full monty transaction style of MDM hub. This is the most assertive MDM style as the hub holds the master data, cleans it and updates the originating system with the correct data. It in effect becomes part of the operational process by which records are created and maintained. This style brings the clearest control but on the flip side it brings with it the greatest organisational cost in terms of process, integrations and accountabilities.
Whilst it can be tempting to consider MDM styles as a maturity model with you starting with registry, graduate to consolidation, climb to transaction and celebrating when you reach the summit. This would be misleading and ultimately wrong as many organisations deliberately use more than one style as it’s possible for styles to coexist. A company may use registry capabilities for one domain, consolidation for another and a more centralised process for a particularly sensitive data set.
The proper way to read the styles is as a spectrum of intervention. The further along the spectrum, the more the hub can do and the more the organisation must accept its authority.
So, to summarise and tie everything together we can say that the confusion and complexity around MDM hub styles comes from pretending they are more technical than they are. In reality, the question is simply how far should the hub be allowed to interfere? At the mild end (virtual style) it’s little more than pointing to data that lives elsewhere whilst at the heavy duty end, we have the hub in full control.
Ultimately MDM is a choice about power: how much should remain with the source systems, how much should move to the hub, and who is trusted to say what the organisation actually knows.