The Truth About CDI Hubs and Why They can't become True Multidomain MDM Solutions
Many vendors today are claiming to provide "multidomain master data management", an extension of their original focus on Customer Data Integration (CDI). They argue that their solutions can be used to manage any master data domain such as products, assets, locations, financial hierarchies, etc.
Is it true? Can a solution originally designed for B2C customer data integration use (mainly transactional hub with matching capabilities) be applied to other master data domains?
Well, we don't think so. At Orchestra Networks, we believe that customers should be aware of the strong limitations of the CDI "has been" solutions. The most common argument against CDIs is their lack of workflow but there are also structural weaknesses that could raise the cost of your MDM project and put the business value at risk.
To validate this statement, we had the opportunity to attend several real CDI product demos. This exercise was very useful and I would like to share our findings. I won't mention specific product names, but if you're involved in an MDM product selection, you'll probably recognize them.
1) Rigid data models
The first solution we tested is a former CDI solution acquired by a fairly large vendor and "repositioned" as a multidomain MDM hub. During the demo we tried to understand how this solution can handle multiple domains.
First, data modeling is nothing more than generating relational tables in an RDBMS. There is no way to define —inside the model— complex data types, embedded business rules, many-to-many relationships, inheritance, object-oriented aspects, etc. In a transactional hub used for managing B2C customer records it probably works (after all, customer models are fairly simple), but for a product master or for complex financial hierarchies, it doesn't meet the test. The richness of the model needs to be coded outside the model, which means there is no way to dynamically generate a comprehensive UI (User Interface) and services.
Then we tried to define two domains. We ended up creating two databases, with two stewardship UI's and no possibility of defining integrity relationships between domains! The result: it creates new silos on top of existing silos.
Relying on a relational-only model is a structural weakness of former CDI solutions. If you try to tweak it for defining complex models, you'll most likely end-up developing a lot of custom code.
(Note: I don't say that having SQL access to your master data is useless. Actually Orchestra Networks EBX5 now offers this capability in addition to its DataServices.)
2) No version control
The original CDI solutions were weak on version control. This is not a surprise since it is not an actual requirement when you deal with B2C customer data. You have one version of your customer data, with just a history of changes.
But in other scenarios such as product master, organization charts, financial or HR hierarchies, you need to manage dozens of concurrent versions, in present, past and future. You need to perform impact analysis ("as if"), comparisons ("as of") and ultimately reconcile versions.
So in our product demo, we tried to define two versions of the same product list. The result was basically two distinct instances, without any way to compare and merge those versions.
This is another structural weakness of CDI solutions. Once again, the lack of sophisticated version control will force you to tweak the solution in order to reproduce it.
3) No real authoring UI / Workflow
Then, when it comes to the "governance" UI we quickly understood that there are no real workflow or authoring capabilities. This is logical since in a pure CDI scenario, you don't need to "author" customer data but review duplicates and perform simple stewardship tasks.
Also, since the data model is relational-only, there is no way to dynamically generate the UI as there are no "semantic modeling" capabilities in former CDI solutions.
So you'll need a significant amount of custom coding and third-party tools to build your own UI on top of the hub… you'd better build your own MDM.
When evaluating multidomain MDM, it is also important to understand how the solution reacts to both data model and business rule changes. Again, while a customer data model is fairly stable, other master data may require data model updates on a regular basis, so it is critical to absorb those changes on the fly, without any specific development.
4) Worst case: the Registry
The final demo we attended was of a registry-style MDM solution.
Basically the idea of an MDM registry is to define a very simple data model that only handles links to actual master data stored in systems. These can be very useful in some CDI scenarios where there is limited value in moving customer data from transactional systems to a central hub and you just want to get a "single view of X".
But can you imagine how difficult this would be for financial hierarchies, products or assets? It just doesn't work since you need to actually control the data to perform authoring, workflow, version control, etc.
Before selecting an MDM software solution, we strongly recommend that you look at the key characteristics of your master data and consider your business users' requirements. Claiming to be multidomain is not enough-make sure you have the answer to these questions:
What is the complexity and the volatility of my data model?
What are the relationships between data domains?
What is the life cycle of my master data?
What are the end user requirements for authoring and collaboration?
How can I apply an agile project methodology to my MDM project with strong business user involvement?
You'll find that outside the B2C customer data integration scenario, CDI solutions are not suitably adapted to multidomain requirements. At Orchestra Networks, our EBX product is a true, model-driven Master Data Management solution. Our most recent version, EBX5 brings unmatched capabilities for semantic data modeling (any data domain, any complexity), a rich governance UI with embedded workflow for business users and full master data life cycle management. In some cases, our customers are investing in EBX while they already have deployed a CDI for pure transactional B2C customer hub.
I would appreciate your questions and comments on this topic.