Master Data Management hub shoot out
Master Data Management (MDM) has evolved over the last couple of years, and it is time to talk about the next version of MDM (MDM2.0). Recently I was discussing evaluation of a hub of hubs concept with one of my colleague. So what does Hub of Hubs means? Typically every organization has multiple LOB's or divisions, that is geographically dispersed, with varying level of IT budgets and procurement objectives. This led to certain divisions having an already existing MDM foot print be it on different platform and on different styles of implementation. The issue is further compounded when there is a Merger and acquisition happening. This blog helps to give an overview of MDM2.0.
Every MDM product is aligned to an industry/vertical domain and follows a particular style of architectural implementation. There are multiple styles of MDM implementation as listed below.
1) Consolidation - Typical for analytical system i.e. reporting, analytics and central reference E.g. Siperian
2) Registry - Typical for a transactional system i.e. registry for real time central reference E.g. Initiate
3) Co-existence - Typical for a transactional system i.e. co-existence for harmonization across database and for central reference E.g. SAP MDM
4) Transactional - Typical for a transactional system i.e. acts as a source of records to support transactional activity E.g. Infosphere MDM Server and Siebel Universal Customer Master.
Going back to the case scenario mentioned above, with various divisional objectives, it is highly likely that at an enterprise may have many transactional MDM hubs -owned and operated by divisional managers. Recently, I was involved in an MDM evaluation proposal for a large contractual legal advisory firm and happened to evaluate a case, where they had an already MDM instance but was unwilling to share the MDM instance with another division. This led to a clash of objectives, with two divisions planning to set up two MDM hubs on different vendor platforms. The implementation is already in progress, but then at an enterprise level this fails to provide a true representation of the customer across division. So what is the solution for this? A hub of hubs?
Yes, the recommended option then is to have a registry hub, set up as the enterprise hub in a true externalized registry style. I.e. It truly represents every customer, with an Unique identifier and a set of common attributes that can be shared across hubs. So the registry hub act as a single referential point, for all customer attributes and acts as the central "read only search based access hub". The other MDM spokes acts as a true transactional hub meeting the divisional objectives and also synchronizes with the central hub using true SOA style integration. The above helps in bi-furcating all enterprise wide search operational into the registry hub and divisional wide transactional operations into the transactional hub. Have you seen a similar implementation scenario or have you seen a business case for implementing a hub of hubs? The aim of this blog is to exchange notes over this implementation style.
Initiate by being the best registry style MDM implementation would fit in the model of a registry hub, while Siebel UCM or Infosphere MDM server would fit in as a true divisional transactional spoke is my perception.
Comments
Jairaj, you have nicely described hub of hubs. However if I try to relate to MDM objectives at a high level then I think ultimately MDM solutions need to work with pretty much all transactional systems and that too with great performance. Won't it hurt to bring in multiple layers? Would it impact the data delivery performance? Just trying to bring in other perspectives to the concept?
Looking at the scenario you mentioned above this may be the solution, but could it be an option to choose an in between solution for both the divisions to agree on? May be the new division uses an registry style Hub, and can refer to existing division Hub as well other application silos where customer data resides? This may look like hub of hubs for any new application coming on board and accesses the Registry style hub system, but with a promise to go into one Hub in longer term provided the differences are addressed between divisions.
Posted by: Prabir Majumder | August 24, 2009 12:45 AM
Prabir,
Let me thank you for your comments.
First thing first. Not every client is looking for a transactional style of MDM implementation. Let me explain with an example. Imagine a health care provider, that has a dual operating model i.e. manages patient operations and also do drug discovery, including clinical trial.
If we are proposing MDM architecture for this client, we could recommend Initiate for the eMPI (enterprise master patient index) implemented in the registry style (it can support more than 1000 tps and is optimized for search operations).
Alternately for the clinical trial-management the recommendation is to have Oracle Life Sciences Hub, implemented as an analytical MDM. In fact interestingly, I received a note from Dan Power stating that Siperian federation capability manages the “hub of hubs” concept extensively.
Hence we cannot recommend, that transactional style MDM is the end all - to all data management problems. As a consultant, our aim is to resolve business concerns and the style of MDM implementation will be aligned to the business concerns. In the illustration given in the blog, the client enterprise architect may have recommended multiple MDM hubs to manage the clearly different business objectives of each division.
Now coming back to the quote on Initiate hub as a preferred external reference registry i.e. registry with extended fields (all the attributes i.e. demographic, preferences, basic details etc. typically associated with the customer including the customer identifier) the data delivery performance is typically higher for high volume searches from Initiate hubs. This means that call center operations, on-line searches, multi channel look-up are optimized with the customer attuned to getting “data on the go” irrespective of the “channels of interactions”.
Agreed, it may be possible to port the registry style implementation of the MDM hub for one division as the enterprise-level transactional MDM hub, but still search operations on a transactional hubs does have limitation in terms of performance bottlenecks, non optimal index for varying search conditions, etc.
Posted by: Jairaj Asok Kumar | August 27, 2009 9:05 AM
Thinking out loud...why should we have only common for master customer attributes. If in companies where governance is weak or nonexistent, what are the cons of having all non-shared non-transactional data in the hub
Posted by: Srihari Hara | July 16, 2010 1:37 PM
Hi Srihari,
Thanks for your note. Let me explain, in a multi geo rollout, we may need a central hub which is used as entry point for all lookup for a customer records. At this point we may need at the minimal the customer representative attributes (name, address, date of birth, gender, address, reference keys, customer reference number and preferences and possibly risk scores (centrally managed) etc). This will be the point of entry across divisions. For a specific region based assessment, the same transaction may get diverted to a transactional MDM.
Now to answer your query, let us imagine a scenario where the data governance is weak and we have recommended storing non-shared non-transactional data in the central hub, what are the implications? The non shared data managing in a central hub is overkill. Who would raise up their hand and state that they own the data? - None. Now let us look at the non transactional data, this is more a reference data set, so what happens if there is a clash between the data set, managing this in a registry hub gets difficult, since none would want to manage this data set. However the transactional system owner will ensure that this reference data gets resolved, as there is a business implication for ensuring that the central hub data is always the golden record set.
Thanks
Jairaj
Posted by: Jairaj | July 21, 2010 9:00 AM