Stylish Master Data Management

This article sets out a description of three architectural styles for master data management.  In reality, just one of these will be practical in most cases.

The article neatly summarizes three styles for implementing a master data management technology, "registry", "hybrid" and "centralized".  It is an irony that master data management, which deals with the problem that data is classified in multiple competing ways, cannot as an industry agree on its own terminology.  Hence you may have come across other terms for MDM styles, such as "transaction" (which in this case is the same as centralized) and "consolidated" (which this article does not fully address).  However the descriptions used in the article are well laid out and indeed represent some of the main choices for an MDM architecture.

In my experience, one of these styles is nigh-on impractical.  "Centralized" (also called "transaction") implies a wrenching architectural shift whereby the a master data hub becomes the one and only source of master data for an enterprise, replacing the functionality of generating master data in existing transaction systems, and serving up "golden copy" data to other systems, perhaps via an enterprise service bus architecture. This sounds elegant, but is extremely invasive.  Many of the core transaction systems will be packages, which are almost certainly not designed to have some of their core functions disabled n this way.  Moreover the sheer politics of handing over control of master data to a single, centralized hub in head office is likely in itself to be a major obstacle in most companies.  Finally, if you somehow sauced despite the odds, you will have a single point of failure for all your key systems, with extremely demanding performance characteristics for an uber-hub which will control all types of master data.  Despite this style being bandied about in the media, I have yet to encounter it in practice.

The registry style is non-invasive, since it leaves the master data where it is, and simply registers the location of the various sources.  Resolving data inconsistencies is dealt with after the fact.  A major issues here is that data quality is essentially not in the picture, meaning that if data is of poor quality at the source system then it will stay that way.  This is a major drawback of this style, quite apart form the potentially severe performance issues of dynamically addressing potentially large amounts of master data across many systems.  Registry may be a good first step in an MDM program, but is unlikely to be the end game.

In most cases the "hybrid" (aka "co-existence") will be what you end up with.  Here you put in a persistent hub for a copy of the master data, and resolve consistency issues there, but leave the operational systems alone in most cases.  The new "golden copy" data can be served up either to data warehouses or indeed back to the operational systems that can cope with such an approach.  This is a less elegant but more practical approach, and I believe is the one that most companies will actually end up adopting. You do still have the problem of co-ordinating changes to the master data between systems, but this is a problem that you are going to have to deal with anyway in most cases, since the "centralized" approach is so hard to implement in most cases that it will be impractical.

I believe that managing a federation of linked hubs is what will be eventually required by most companies, avoiding issues of over-invasiveness, yet providing a high quality source of key master data which can be used by other systems where needed.  Unfortunately the co-ordinating of such a federation is still your problem, as the MDM vendors have barely begun to address the issue of managing such a linked federation of hubs (few companies have taken MDM that far yet, so have yet to be demanding this kind of functionality).  I believe that this will be an important differentiator for vendors in the coming years.

This author consults with leading institutions through GLG