The MDM Tarpit

As I look over my Governance landscape I find that I struggle to see how MDM (Master Data Management) really fits into it. “Master Data” isn’t something new, as far as I can see, it’s just data. And I was brought up to analyse data as part of building an automated system, as part of understanding the (business) problem—before coming up with a solution, which included managed data. Solutions to problems you don’t fully understand are usually high risk.

So I don’t see a need for “master data”, there’s just “data”. “Good governance” says that it should be maintained, logically, in one place even if it is physically duplicated (but under automated control, not just ad-hoc duplicated as people feel like it) wherever it is needed, for performance reasons. There is a customer entity, and it probably has a customer number and domain-specific names—but everyone should be using the same customer number and the domain specific names should refer back to the single entity. “Obviously” the same applies to the product catalogue and so on—although with things that are “obvious” there is often a small devil hiding in the detail.

However, in my opinion, if you have an MDM project, this is prima facie evidence of poor governance in the past. If you couldn’t manage your data properly before, once the initial euphoria of buying your shiny new MDM software has worn off, won’t you make the same mess of the “master data” that you previously made of your original data? After all, a fool with a tool is still a fool—what has changed?.

Which all means I am a little puzzled by the popularity of MDM—why make a public fuss over admitting poor governance of your data and development processes? But I think I understand now—MDM isn’t a “solution” in the accepted sense, a good practice way of doing things; it should be thought of as an “antipattern”—a temporary or expedient fix for bad practice which includes a documented path back to good practice.

An antipattern is the documentation of a superficially attractive but dysfunctional situation (a tarpit you can’t easily escape from), together with a description of how you got into this dysfunctional situation in the first place and a description of how you can, if you are prepared to put in some discipline and effort, get out of it and return to good practice.

So, how do you get into the MDM tarpit? Losing control of development is a good way. I remember a scripting guru saying that development was much faster and more efficient if you gave every developer their own database. I think I can see how this might work (cloned databases from a single data model, with strong change management for changes to the metadata) but I bet this attitude really results in a confusion of (at first) slightly different but overlapping domain-specific data structures. Of course, an even easier way into the tarpit is to forget about data analysis and even proper databases altogether: after all, who needs them when web services” happily lets you mix apples and oranges as long as they fit into the same length field?

But there is one excusable reason for finding yourself in the MDM tarpit—consolidating autonomous parts of your organisation; or taking over or merging with another company with a complete set of systems overlapping your own, will put you there quite neatly. Well, I say “excusable”, but it does occur to me that even here a bit of enterprise architecture modelling and up front planning might have helped you to avoid the tarpit.

Enough; what you want to read about here is something positive, about how to get out of the tarpit. It is well-known (irony alert) that doing things wrong and plastering on a quick fix is always more cost effective than doing things right in the first place (besides, doing things right is boring and uncreative). Luckily, a host of software automation solutions for MDM are available to help you—and you won’t need me to tell you about them.

Unfortunately, as you won’t be surprised to learn, I believe that these software solutions are necessary, but not sufficient. You need to address the cultural and management issues which got you into the tarpit as well—you need to introduce “good governance” to ensure that you don’t fall back into the tarpit.

So, when you’re out, it’s going to be important to carry on with MDM religiously, before you fall back into the tar? Wrong! Once you get out it’s important to start to manage your data properly at the metadata level—all data, not just your “master data”. After all, what is fairly static “master data” to you may be “transactional data”, to me, in my application.

Once your master data is under control you should expand your “master” data management to include all data that is important and shareable—which is all of your data (storing lots of unimportant data that no-one much wants to use is pretty poor governance, in my opinion). If your MDM tools help you to do this, all well and good—but don’t build an MDM silo. Look at and re-evaluate the system architecture tools and data modelling tools that would have helped you avoid the expensive detour into the MDM tarpit in the first place—if you’d used them properly, in the context of the delivery of a business service.