Dispelling the MDM Myth, Part 2

If you don’t want to confuse, be careful of the terminology you use!

Wow! When I posted my article “Dispelling the MDM Myth” last month, it seems like I really opened up a can of worms – mostly in a good way.

While it was easily the most popular blog post I wrote last month (getting nearly double the number of hits that the next most read post received), what became apparent through various group discussion threads on LinkedInis that the “MDM” acronym isn’t nearly as well understood or universally used as I had anticipated. (e.g. here, here, here and here) There were various comments to the effect of “what do you mean by that”, “please stop using unfamiliar terms” and “I don’t understands” going on. (Bear in mind that the groups that I had posted to are all focussed on the practitioners and professionals within the Information Management & Data Governance community, rather than being more general business user groups where I might have expected a higher level of unfamiliarity.)

Lesson for me? Make sure you always do a “Humpty Dumpty” and define your terms whenever you use a piece of jargon, even if you think your audience is totally familiar with the domain! If nothing else, it ensures that you’re all on common ground and discussing the same thing within that topic. e.g. one commenter identified that in certain circles, “MDM” can refer to “Mobile Device Management”.

(Aside: all this also made me wonder whether there is also still confusion when it comes to  terms such as "Business Intelligence" (BI), "Data Warehouse" (DWH), "Customer Relationship Management" (CRM), "Enterprise Architecture", "Cloud Computing", "Big Data" etc.?)

Anyway, with Humpty-Dumptyism in mind, I thought I should clarify my general overview of what I take Master Data Management (MDM) to mean - if nothing else for the sake of disambiguation within my own mind!

• The term "Master Data Management" (MDM) is a well-documented and accepted phrase within the Information Management & Data Governance arena as a generic catch-all for a wide range of complex and inter-related disciplines affecting the processes, methods, architectures and tools of administering core categories of descriptive and categorising reference data. It is prevalent within the Information and Data Management sector and the acronym is in wide use in our industry. (Web sites such as those by IAIDQ, MIKE2.0 and DAMA are useful to gain a broader understanding). 

• The originating "golden record" of ANY data record should ideally be managed according to principles of data mastery, and on that basis "Master Data Management" would refer to the disciplines of curating the originating source of all such data, with every other usage of that data becoming an integrated and dependent read-only copy. 

• However, the term “Master Data Management” in its current common usage focuses on the disciplines of co-ordinating the data values and member records for key sets of "master" reference data (the Product list, the Customer list, the Locations list, etc). These lists of reference data records get re-used as look-up data sets in multiple transactional systems - they are what gives each transaction record it's context and meaning. (In data warehouses and Business Intelligence solutions, the Master Data sets become the member records within the "Dimension" tables, while the transactional records become "Fact" tables.)

• Unfortunately, very often these "master" data sets don't get co-ordinated terribly well - each transactional system can end up maintaining a local copy of the data, and we end up with inconsistency of the data. This can happen even if the core "enterprise" data model which defines the expected structure of the data is well defined and the metadata structures for all the systems are properly maintained.

• Coordinating and maintaining the Master Data sets requires specific process and organisational disciplines that are part of the business function, not IT.

I would make the point that the summary of "MDM" that I've offered above reflects how I perceive the term to be in general and pervasive use across the industry and in particular as appropriated by the software vendors. (i.e. the management of common reference & contextual data sets only.) Depending on your point of view, that may be unfortunate, or even "wrong", but it is how things are. 

In that respect, it's not really "my" definition - and anyone who thinks I've got enough influence within the Information Management sector to affect a change to this received usage is A) significantly flattering me and B) delusional!

As I implied in my original post, I think part of the challenge is that the technology vendors will always appropriate any fashionable term and mis-direct it to fit their own particular agenda - which means no standard understanding and we have an Information Management "Tower of Babel" on our hands. Once we go beyond a simplistic and generic understanding of the discipline as a whole, different software and services vendors tend to use such terms to mean subtly different things dependent upon their own purposes and tend to focus on the technology aspects of data management, rather than dealing with the human elements. 

We've seen this with "Business Intelligence", we've seen it with "Big Data", we're now also seeing it with "Data Governance" - which I've seen used to describe anything and everything from ETL mapping tools, metadata repositories, security management software and even just data storage.

In my view, purchasing a software product will (almost) never a panacea end to all your problems - it will be the starting point only. The "80/20" rule applies pretty well - 80% of the effort, cost and general heartache for any successful deployment will relate to "human" elements (organisational, educational, cultural, behavioural, process/procedural) and 20% will be about technology delivery.

In my 20-plus years of doing this schtick, I've encountered very, very few product vendors (and all-too-few services providers) who take this mindset into a project. In the MDM space, the French business Semarchy are one such business, while in the Data Governance area, Collibra seem to be saying many of the right things (which is reflected in Forrester's latest Data Governance market analysis). IBM's Information Management division are now getting there, but it's still patchy. After that, it seems to be tools and features all the way...

If I was to be REALLY cynical (surely not...), then I'd offer that from a project management perspective, it's the human elements that bring almost all the risk, so as someone bidding to implement a solution for a client, the very first thing that you'll want to do is manage your risk by excluding any human factors from your contracted scope. It also means that the "core cost" of a project will appear much lower - which is great if you're trying to get a Business Case past an unsuspecting Executive group, but hopeless when it comes to the reality of getting anything done. Result - project failure.

(See my recent discussion paper on Distributed Data Quality for some alarming statistics on how many information management projects fail to meet expectations):
http://www.informationaction.blogspot.com.au/2014/03/new-white-paper-distributed-data-quality.html)

As an industry, we've collectively bought into this "Emperor's New Clothes" delusion. Clients need to be less naive, vendors need to be more ethical.

So in summary - if you ever come across anyone who does take a "humans first" approach, treasure them and don't let them go!

Key message #1: beware the vendors!

Key message #2: All of us within our industry have a responsibility to contribute to the ongoing education and change process. We do what we can, and we all benefit if we help each other.

I really hope that’s now cleared everything up!