Alternative title for this blog: It’s all a question of Hubs – and how many….
MDM is many things. For me, one of the more interesting things that is described by MDM is actually the beginning of a hugely important dialog between business and IT. It goes like this….
After 30 years we have discovered that though we have many and multiple business applications, each one with their own data silos, the truth is that each and every silo assumes authority over its own data. Some of us have learned that this is both a travesty as well as a fallacy. Common data shared between applications, what we now call master data, should not be authored in each individual application. Nor can it simply be “integrated” by mapping one field to another. This data needs to be authored in one location (or application) and synchronizes among the others that need it. Note that I do not say that there needs to be a reduction in the number of copies of this data. That might be a worthwhile effort, but that is not actually that important. What is important is the recognition that:
- Master data needs to be governed outside, independent and in support of, all applications
- Master data should be stored in a location that is efficient with respect to usage, access and governance
The result is now what we call MDM and with that, MDM solutions to help with the effort. Some MDM solutions have developed that are good at storing common customer master data, and some others at storing common product master data. There is much hype in the market about single domain versus multi domain MDM, but that’s for another thread/blog. What I want to talk about now is what’s next, and what is the point of MDM in the first place?
In truth, a growing number of end users have charts on their walls that look like this:
Increasingly users have determined the need for a single master data hub of some design, for the core master data. This might be for one data domain, or several. A few end users get a rush to the head and start to move lots more than master data into that hub, such as application data, and this tends to cause the program to fail at some point. Some tend to soldier on. Smart end users keep the program focused on just master data, then they start to ask themselves about the flow of data (should it flow from app to hub, or from hub to app?). Finally, after this, some other more interesting questions come to mind:
- How many master data hubs do I need, once I know I should store app specific data locally and not in the master data hub?
- What do I call these other local data hubs? Is this CDI, or PIM? What do I call the effort, the program, the business case, for these other hus?
- How and when will all my applications (and vendors) actually accede to external information governance?
- Where to I locate these hubs – with “all applications”, or sets or subsets of applications?
MDM has been a great ride, but it’s really just the first stop along a long, long ride. We need to get on the train and get moving. We need our application vendors and application designers (and strategists) to ‘open up’ and start to expose their semantics and metadata. We need to focus less on data and application integration, and less on API design, and focus first more on semantic exposure for interoperability. On we have a shared language, the effort and methods of data exchange between hubs and applications will become simpler. No amount of integration magic can cope with this complexity. Every dollar that seeks to improve the exchange (read ‘integration’) mechanism is just bad investment after a lost cause.
MDM led us to ask some very good questions. But we have only just started to ask the important questions. The next set of questions, beyond MDM, may show us just how far the rabbit hole goes.