Say NO to MDM and YES to Collaboration Improvement!

I’ve had the opportunity to either participate in or be witness to a couple of Master Data Management (MDM) and Enterprise Data Management (EDM) initiatives. They all had something in coming: failure! For a while, I almost believed that I had bad karma and was the root cause of these failures.  Happily for me (but not for MDM), through peer and forum discussions, I was rapidly reassured that I wasn’t alone. There seems to be very few (not to say any) sustainable success stories with regards to MDM and EDM. The question now is “WHY?”

Over the last couple of years, I’ve been pondering this question. My present conclusion is that “MDM addresses a symptom and not the causing issue!” How so you are probably wondering. To understanding how I came to my conclusion, we have to go back to what MDM and EDM are all about.

MDM (which I will use as a substitute for EDM for the remainder of this article) is, as its name implies, about the management of data which is considered master (official) for the enterprise. So what isn’t master data? Well, most of the literature on the subject defines MDM to be concerned with key reference data which is necessary to run an enterprise. Simply defined, reference data is data which is not transactional in nature but rather data which enriches transactional data with contextual information.  For most organisations, data such as product, customer and supplier would be considered reference data. In contrast, data such as sale line items, deposits or purchases would be considered transactional. As a side note, I would like to point out that what is considered in each category is contextual and not universal. For example, for a bank, customer information would be considered reference data which enriches transactional data such deposits, service purchases; however, for a calling list firm, each potential customer they collect could be considered as a transaction which is enriched with data such as country. End of side note. 

Typically, enterprises use MDM initiative in order to address two data related challenges: lack of shared vocabulary and lack of data quality (inconsistencies, undefined sources, etc.). The expected outcomes of an MDM initiative are:

  1. (1)    a common vocabulary for master data in order to address semantic and interpretation inconsistencies;
  2. (2)    identified official sources of master data domain in order to address data governance issues (where is the source of truth) ;
  3. (3)    quality expectations for each data domain in order to address data quality issues. 

About now, you are probably wondering “This MDM stuff sounds good.... what’s the problem?” Well, I believe the underlying assumption of MDM is “if I can get the right people in the room to discuss our data quality and governance issues, and if the people are reasonable, we can solve these issues with more clarity and There seem to be no bound in today's world. structured governance”. I think this assumption is wrong! Wrong because it has nothing to do about people being reasonable, has only somewhat to do with clarity and governance. Here’s why.

All enterprises have an endeavor, something which they are trying to achieve. Their principal means of achievement these endeavors are people and technologies. One such technology is “organisations”. Hence all enterprises are undertaken by an organisation of people. Typically, the result of such “organising” is that people are divide into non overlapping groups with specific tasks to accomplish. In order to achieve the endeavor of the enterprise and not only the ends of each group, these groups most collaborate together. The main technology which people use to collaborate is language and dialogue. With the advent of IT, language and dialogue (albeit very inflexible dialogue) can be implement through the exchange of data between groups. From my experience, the data domains which are considered master in an enterprise are those that are used across the organisation (vertically and horizontally); the data which support collaboration. Consequently, the data issues that haunt enterprises, most often than not, are symptoms of collaboration issues.

It is hard to define what collaboration is so I won’t; however, I will share what I believe to be 3 organisational patterns of poor collaboration. The first pattern is lack of shared meaning and understanding. This happens when people don’t have a shared language to discuss something, or worst, that they are under the illusion that they have such a language but are really using shared terms to convey difference meanings. The second is the perception or the existence of unwanted behaviours in other groups by some group which is not capable of accomplishing their task because of the former. This one shows up in the form of somebody not getting the right data (or of the right quality) from another group despite clear requests. This one is often a symptom of silo thinking, acting and management. The consuming group doesn’t understand the low importance of the request from an enterprise perspective or the producing group doesn’t understand that the high importance of the request an enterprise perspective. This pattern is about the lack of a common ends -what we are collaborating on; it’s about the lack of holistic thinking, acting and management. The third pattern is the absence of shared direction. This one is the “we are lost syndrome” which causes people/groups to all go in difference direction. This one is about lack of shared direction for collaboration. All these patterns are organisational in nature and not technological. In a healthy organisation, nothing would stop people from sitting down together an addressing these. When somebody is not capable of doing their task, they would just pick-up the phone, call the appropriate people and say something like

  1. 1. “I don’t think we have a shared understanding about the data we are sharing, can we talk about it?”
  2. 2. “I’m having difficulties doing my job bases on the data you are providing me, could we discuss if we should adjust our tasks given the objective of the enterprise?”
  3. 3. “I don’t think we are going in the same direction, let’s sit down and resolve this.”

In the organisations I have experienced or heard about, the above conversations never take place. People view these data problems as IT issues, not organisational ones. Consequently, MDM initiatives often only address the symptoms of the problem not the real issue which is lack of collaboration. So going back to the underlying assumption of MDM, if you agree with me, we can see that the “reasonable people around the table” expectation just doesn’t hold. If you could get them around the table for the MDM initiative in the first place, their probably wouldn’t be a need for MDM. So the question now is “what do we do about it”. The challenge is that by design, the way we organise and manage people in the today’s enterprises tends to foster silo thinking and behaviours. This should come as no surprise. Most contemporary organisations use structures based on Tayloristic principles which is all about specialisation and absence of collaboration!  Organisation must strive to achieve collaboration improvement, not MDM. Maybe through such improvement, a shared language will be created or governance defined but they will be means not ends.

James Lapalme PhD is an Enterprise Architecture consultant and researcher. He has obtained a PhD, a MSc and a BSc in Computer Science from the University of Montreal as well as a MA in Human Systems Intervention from the University of Concordia. He has contributed, as an enterprise architect, to work which has been the subject of case studies by Gartner and MIT-Sloan. He has also published a number of book chapters and journal articles on systems engineering related topics. He may be reached at This email address is being protected from spambots. You need JavaScript enabled to view it.

Comments (0)
Only registered users can write comments!