"An extraordinary thinker and strategist" "Great knowledge and a wealth of experience" "Informative and entertaining as always" "Captivating!" "Very relevant information" "10 out of 7 actually!" "In my over 20 years in the Analytics and Information Management space I believe Alan is the best and most complete practitioner I have worked with" "Surprisingly entertaining..." "Extremely eloquent, knowledgeable and great at joining the topics and themes between presentations" "Informative, dynamic and engaging" "I'd work with Alan even if I didn't enjoy it so much." "The quintessential information and data management practitioner – passionate, evangelistic, experienced, intelligent, and knowledgeable" "The best knowledgeable, enthusiastic and committed problem solver I have ever worked with" "His passion and depth of knowledge in Information Management Strategy and Governance is infectious" "Feed him your most critical strategic challenges. They are his breakfast." "A rare gem - a pleasure to work with."

Monday 7 July 2014

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!

11 comments:

  1. I have often thought it ironic that there are many different definitions in use for MDM. Surely we need a golden record for the piece of reference data that is the term 'MDM'. Out of interest I tend to use MDM to represent the technical side of the people, process, technology triangle with other facets of data/information governance covering the other 80% (I also do not claim to be 'right'). This aligns with your point about vendors: most are MDM (technology) vendors and not purveyors of the human element. If you wanted a new garden wall they (the vendor) would sell you the bricks and mortar and deliver them to your house; you then have the choice of designing and building it yourself or bringing in professionals. I'll leave it to you to complete the metaphor.

    ReplyDelete
  2. Thanks Stuart. All of the industry fora that I mentioned (DAMA, MIKE2.0, IAIDQ) have some form of position on what "Master Data Management" means, as do all the tech vendors, as do all the Systems Integrators. It's them "buyer beware" to navigate all that and get the best outcome you can.

    I'm also reminded of this cartoon: http://www.mbird.com/wp-content/uploads/2011/08/standards-1.png

    ReplyDelete
  3. I completely agree and love the cartoon. It is down to us to use a pragmatic definition based on the situation.

    ReplyDelete
  4. Studying philosophy (that great introduction to KM) - I loved the concept of phenomenonology, where our own cultural or inherent biases or conditioning would lead to a predictable outcome.. the potter views a Rorschach pattern as a vase, and the gardener sees a flower. The common phrase 'If you only have a hammer, every problem looks like a nail' - Who could say that Individuals working primarily working with machine based solutions don't see humans as inherently a little bit messy and unpredictable, so it'smuch easier to exclude them from the equation? I would like to think my KM hat can be worn simutaneously with my IM one, and I can cconsider not only how to source, store, categorise, manipulate, display and transmit those bits and bytes, but how people might need, interpret, and want to use them to meet a real need.

    ReplyDelete
  5. Thanks Doug - seeking confirmation of a predetermined outcome is a classic challenge within information management. As well as the philosophical angle, it's also well-documented as a psychological phenomenon. (Being married to a Psych major means that I more-or-less get to claim a psychology degree by osmosis!)

    Information Management & Knowledge Management are certainly complementary (and closely-related) disciplines and I agree that an approach founded in KM principles is helpful when examining and conveying the utility, narrative and value of information.

    ReplyDelete
  6. Alan, the approach we used for Information management is "human first" which won us the DQ Asia Pacific award. To me, process, technology and tools supporting an IM initiative are the easy bit, dealing with humans and the associated culture is the biggest challenge of all!

    ReplyDelete
  7. Thanks Ram. Your own situation is exactly the kind of example that gives me hope that this can be done! People are always the problem - but they don't need to be, if they're the heart and soul of things.

    Sadly, it is seldom thus... (Although at least it ensures there's gainful employment for those of us who think and work that way!)

    Yours aye
    ADD

    ReplyDelete
  8. From Martin Renhackkamp on LinkedIn:
    "Alan, most definitely there is not a common understanding and agreement on terms such as "Business Intelligence" (BI), "Enterprise Architecture", "Cloud Computing", "Big Data", not to mention "X-as-a-service". And yes, to a lesser extent, but some clients are even confused about what a "data warehouse" is supposed to be too...
    So I agree totally with your point that we should always define the terms we use and continuously educate the client base."

    ReplyDelete
  9. To answer Martin's point, I'd say that as an industry, we're certainly guilty of having multiple terminologies for the same thing, which leads to confusion at best, obfuscation at worst. It's up to those of us who have the temerity to define our terms before proceeding to try to hold the line, continue to raise awareness, and hold the industry at large to account. It's an uphill task, I have no doubt!

    Bad enough that we don't know whether to call something a spade or a shovel. But there's also something even more pernicious. Time and again, we see vendor companies actively invent (ugly) new language to try and give the impression that what they're doing is fresh, innovative and exciting (I'm accusing both product vendors and systems integrator/consulting services business here!). Whereas more often that not, they're just re-badging existing ideas to fit with the latest round of Bullshit Bingo hype. "Manually operated excavation device", anyone?

    "Big Data" and "Data Governance" are just the latest in a long line of bandwagons that every vendor is trying to jump on right now.

    The latest example of this hit my desk only this morning - some bright sparks are now re-badging Service Oriented Architecture as "API Governance" (on the pretext that SOA is dead and a bad idea, but APIs are the way forward and the greatest thing in integration since electronic sliced bread).

    I died a little inside today...

    ReplyDelete
  10. Hi Alan - great work. (Lots of work!) How about MDM vs Enterpise Data Management (EDM)? Vendor-speak big time EDM capability! Cheers, Mark

    ReplyDelete
    Replies
    1. Thanks Mark. Yet another "define your terms" challenge...

      I've seen the words "Enterprise Data Management" used to describe everything from tiered storage to database systems, and from data migration to archiving.

      *sighs*

      Delete