The TLAs (Three Letter Acronyms) in the title of this blog post stands for:
- Customer Data Integration
- Product Information Management
- Master Data Management
CDI and PIM are commonly seen as predecessors to MDM. For example, the MDM Institute was originally called the The Customer Data Integration Institute and still have this website: http://www.tcdii.com/.
Today Multi-Domain MDM is about managing customer, or rather party, master data together with product master data and other master data domains as visualized in the post A Master Data Mind Map. Some of the most frequent other master domains are location master data and asset master data, where the latter one was explored in the post Where is the Asset? A less frequent master data domain is The Calendar MDM Domain.
You may argue that PIM (Product Information Management) is not the same as Product MDM. This question was examined in the post PIM, Product MDM and Multi-Domain MDM. In my eyes the benefits of keeping PIM as part of Multi-Domain MDM are bigger than the benefits of separating PIM and MDM. It is about expanding MDM across the sell-side and the buy-side of the business eventually by enabling wide use of customer self-service and supplier self-service.
The external self-service theme will in my eyes be at the centre of where MDM is going in the future. In going down that path there will be consequences for how we see data governance as discussed in the post Data Governance in the Self-Service Age. Another aspect of how MDM is going to be seen from the outside and in is the increased use of third party reference data and the link between big data and MDM as touched in the post Adding 180 Degrees to MDM.
Besides Multi-Domain MDM and the links between MDM and big data a much mentioned future trend in MDM is doing MDM in the cloud. The latter is in my eyes a natural consequence of the external self-service themes and increased use of third party reference data which all together with the general benefits of the SaaS (Software as a Service) and DaaS (Data as a Service) concepts will make MDM morph into something like MDaaS (Master Data as a Service) – an at least nearly ten year old idea by the way, as seen in this BeyeNetwork article by Dan E Linstedt.
Liliendahl on Data Quality 
I like this post and to be honest Henrik, I would contend that the idea of “domain” is dead. It only matters these days to vendors with single domain products (ex-CDI or PIM products) or those mega-vendors that have acquired different technologies over the years to address each domain… plus of course Gartner who have a separate MQ for each domain, they care!
In the modern world of non-intrusive, agile, genuinely multi-domain MDM products the concept of separate domains is rendered almost irrelevant. If the business can explain the relationships between entities and you can model the data then you should able to master it in a hub.
Semarchy will be at the DG & MDM Conference, London 19/20 May – http://www.irmuk.co.uk/mdm2015/
Thanks for commenting Richard. I think it is always a balance. Looking myopic at one master data domain at the time is not always useful, but slicing the space does sometimes help with priorities. The same can be said about sell-side versus buy-side, which is a common way of dividing the world on the business side, but also a not so useful root cause for silo thinking. You may even challenge looking at master data versus other data.
That said, the market needs true multi-domain MDM solutions (as well as the market needs specialized solutions for specific challenges within the different domains).
It is good to see that Semarchy focuses on true multi-domain MDM with emphasis on being agile and non-intrusive.
Henrik,
I would tend to agree with you and respectfully disagree with Richard. At Verdantis, we focus solely on materials master data and over the last few years, we have had many clients that have approached us when a multi-domain MDM solution was not able to manage their item master.
While we might look forward to a day when multi-domain solutions will evolve enough to be able to handle the nuances of each domain, I feel that in the current scenario (and for quite a few years to come) the expertise that single domain vendors bring to the table are valuable and worthwhile.