In the world of MDM there appears to be an odd discussion going in around whether "multi-domain" MDM is required or not. What is multi-domain MDM? Well the first thing is to understand what product companies mean by multi-domain and what businesses mean by the same term
They mean in other words the different types of entities that you are managing. So do you just manage the customer entity, just the product entity or manage multiple types of entities. Sometimes this views suppliers and customers as being in different "domains" as they might have a different database structure. The point here really is that these are very much a technical view of a domain driven from a product perspective. The question the vendor is asking is whether your MDM programme is going to manage one or more tables in a database and managing multiple tables makes you multi-domain.
So Multi-domain for product vendors is actually asking about the database schema and how many tables you want to manage. This question is driven very much from the type of MDM solution that a vendor has and linked very much to what their product can actually do from a database schema perspective rather than a business outcome view.
So what about the business? Does this entity view match the business view of domains? No not really, in fact not at all.
The business looks much more at the concept of business domains.
- Customer Centric - Focused on adding value and customer interactions
- Enterprise Centric - Focused on driving efficiencies and consistency internally
- Supply Centric - Focused on driving cost out of the supply chain
In each of these areas the product vendors question of "multi-domain" is irrelevant because quite clearly you can't do any of these things without considering the full trinity of Party, Asset and Location. You can't understand your customer if you don't know what products, and particularly what type of products, that they buy. You can't create more internal efficiencies through HR if you don't know the skills and locations of your employees and you certainly can't drive cost out of your supply chain if you don't know which products come from which suppliers.
Multi-domain MDM therefore is a pointless question from a business perspective. You don't want to do supply-centric MDM which is focused on cost and at the same time drive it to deliver a single customer view from a business perspective. These are distinct business challenges, which may end up having a common technical solution but from a business perspective they are linked but distinct.
The question of multi-domain therefore is pointless and wrong and asked because people are viewing business problems from a purely technical perspective. Technically MDM should always be looking at all three types of entity information and therefore should technically
always be multi-domain. From a business perspective however you should always concentrate on a single business domain as that is the best way to achieve the right business outcome.
Its an interesting question as to how on earth MDM technologies can even propose a single entity MDM solution to address these multi entity business problems. How to create a single view of a customers position if you are sure they have accounts in ten systems but you don't know if those are credit or debit accounts? How to negotiate between suppliers if you know who they are but you don't know which of the products are equivalent?
So when you look at MDM remember that it is the business perspective which counts not the technical one. MDM isn't multi-domain, its important to concentrate on the single-domain business problem to deliver the most value in that area. You might then drive 3 MDM programmes which share a common MDM technology infrastructure which will support all three forms of master entity information, but the business really doesn't need to know that.
Asking whether you need to
technically do multi-domain MDM is like asking someone when they buy a manual* car whether they want all three pedals or just one from accelerator, break and clutch. So lets move on from technical questions and start focusing on the business outcomes.
