Mike Hudgell, and MDM specialist with Evaxyx has provided an interesting and we think valid view on MDM, which we share with you here:

As with any novel acronym, myths abound around MDM.  It doesn’t help that ‘MDM’ is not exactly the most descriptive term.   On first glance, it is not obvious what master data is, nor how the management of it deserves any special attention over and above normal good practice for data management.  The Wikipedia definition is as good as any, but is in itself so wide ranging that those new to the subject might be left with the feeling ‘so what?’

A little history of MDM can illustrate why the adoption of the term is so confusing.   CDI (Customer Data Integration) and PIM (Product Information Management), whilst sharing the same enigmatic three-letter-acronym mysticism, were an awful lot more descriptive.   Not only that, they were also easy to trace back to business need.   For business-to-consumer or business-to-business organisations, it was easy to see why CDI was applicable, along the lines of ‘Hey, we have customer data, and hey, it needs integrating, so CDI sounds like a good idea.’  Equally, organisations that had demand chain issues, or were used to product information mismatches could immediately see the benefit of resolving these ambiguities in an overall approach driven by PIM.  It is not a huge leap to join the two together, given that both classes of information, customer and product, will require similar approaches to mastering, distributing and standardisation.   But in joining them together, the industry faced a huge task of explaining what this new ‘master data,’ was, effectively abstracting customer and product into the new definition.  We might have gained a cleaner architectural view of the problem, but we certainly lost the immediate appeal of both labels.   A clear case of babies and bathwater.

Of course, the history of MDM doesn’t stop at CDI and PIM, and Tim is right to trace the lineage back to CRM.  Arguably, the drive towards customer master files dates the move to a consolidated view of customers is an even earlier attempt to solve the Single Customer view problem, and that was in the early prehistory of 20 BS (Before Siebel), antiquated by comparison.  What this suggests is that the problems that MDM addresses, certainly on the customer side of things, are not new.  The answer to whether MDM is a meaningless acronym lies in the reasons why MDM should succeed where other initiatives have failed.

The Wikipedia definition, whilst being so wide as to invite more questions than it answers, contains a real kernel of truth.   ‘… (MDM) comprises a set of processes and tools…’ and it here the real gem emerges.   The processes needed to support using master data effectively are at least as important as the tools, yet these are often overlooked, or just filed away under the equally ambiguous banner of data governance. 

Suppose you have a Single view of customer, supported by an appropriate piece of MDM technology, that allows you to perform identify checks and handle possible matches.   How are you going to integrate this capability into your on-boarding processes?   Can the systems you use support this level of integration, and are your business processes adapted to allow for exceptions?  If you have a consistent set of rules to apply to a single view of customer, how are you going to reflect changes in legacy systems?

Understanding how your business processes use master data is crucial before any real attempt to integrate can proceed.  Taking this twin view of process and data is not often emphasised, yet, as Tim concludes, these are the key factors that determine success.

The banner that best describes this approach is Data Governance, but again this is a term that has as many definitions as it does interpretations.   Gaining a single view of customer data, with the implied central applications of rules, requires a connected approach across different parts of organisation.  Often, these separate parts will have had autonomy in managing their customer information, so any measure of centralisation will require an understanding of ownership as well as authority.   SCV and MDM programmes often formalise the role of central or distributed data stewards; either way will require a organisational framework to support collective ownership of the Single View.  This framework must be flexible enough to allow issues that affect multiple business domains to be brokered and decided upon, but not so constraining that the Single View prevents normal operations.

Deciding on truth across many different systems is quite rightly identified in the article as being very difficult, but it does not spell the end for MDM.   In fact, deciding on truth is arguably the feature that mature MDM approaches adopt, and it plays a vital role throughout the lifecycle of a programme.  In analysis, it is vital that the ownership of master data is identified, and the definition clear so that it may be understood across the enterprise.  In the example of addresses given in the Insight article, it would be vital to define what a delivery address was, and a home address, and then ensure that any system that supplied or used that information used the appropriate definition.  

It is in the design of an MDM platform that rules about truth become important.   If it is known that one system provides far less reliable information that another, then rules should be built to encapsulate this.  If a web based system provides low quality addresses because of poor data validation, then that information should not overwrite other information.   The rules that determine truth in central system will naturally evolve, especially as new information sources are marshalled, so that over time, a complex view of the rules that determine truth become embedded in the hub.

If it were just down to good analysis and design to determine the truth of a particular piece of information, then we would be done.  Unfortunately, as many failed attempts to exhaustively canonize all aspects of a business in rule form will attest to, nothing is ever that straightforward.   Suppose your system embeds rules that will deal with 99% of all the scenarios; what about the missing 1%.  Will these sorts of errors persist or propagate, or will they cause the whole edifice to crumble in a heap?   The secret, and perhaps one of the key shifts that accompanies MDM, is the notion that there is always a role for the human eyeball.   For circumstances where it is not clear what an automated rule should do, MDM approaches raise an exception (and usually some workflow) that allow resolution by data stewards.  This crucial feature , aside from any technological ‘bell or whistle,’ that MDM offers, is the admission that while automated rules will increase consistency, there are some things computers just can’t work out.  Once again, here MDM meets Data Governance, as the activities performed by data stewards in managing these exceptions needs to be reflected back into the processes that use this information.

Is MDM another meaningless acronym?   The answer to this is yes and no, rather predictably.  It’s certainly not the most intuitive.   It isn’t, well at least it shouldn’t be, a technological silver bullet.  Its probably misconstrued as such because a lot of the ‘buzz’ that is generated is by software companies.  The softer parts of MDM, Data Governance and process analysis arguably need more attention than the tools, and it is these that will determine the success of using MDM to create a Single Customer View.  Deciding truth in MDM is crucial at all phases; that is not to say that is not difficult!  Getting the right mix of automated rules that handle the most common ambiguities, and stewardship processes to handle the most difficult is the balance that needs to be struck in order to make an MDM programme successful.