How do we go from single-domain master data management to multi-domain master data management? Will it be through evolution of single-domain solutions or will it require a complete new intelligent design?
The MDM journey
My previous blog post was a book review of “Master Data Management in Practice” by Dalton Servo and Mark Allen – or the full title of the book is in fact “Master Data Management in Practice: Achieving True Customer MDM”.
The customer domain has until now been the most frequent and proven domain for master data management and as said in the book, the domain where most organizations starts the MDM journey in particular by doing what is usually called Customer Data Integration (CDI).
However some organizations do start with Product Information Management (PIM). This is mainly due to the magic numbers being the fact that some organizations have a higher number of products than customers in the database.
Sooner or later most organizations will continue the MDM journey by embracing more domains.
John Owens made a blog post yesterday called “Data Quality: Dead Crows Kill Customers! Dead Crows also Kill Suppliers!” The post explains how some data structures are similar between sales and purchasing. For example a customer and a supplier are very similar as a party.
Customer Data Integration (CDI) has a central entity being the customer, which is a party. Product Information Management (PIM) has an important entity being a supplier, which is a party. The data structures and the workflows needed to Create, Read, Update and perhaps Delete these entities are very similar, not at least in business-to-business (B2B) environments.
So, when you are going from PIM to CDI, you don’t have to start from scratch, not at least in a B2B environment.
The trend in the master data management technology market is that many vendors are working their way from being a single domain vendor to being a multi-domain vendor – and some are promoting their new intelligent design embracing all domains from day one.
Some other vendors are breeding several platforms (often based on acquisition) from different domains into one brand, and some vendors are developing from a single domain into new domains.
Each strategy has its pros and cons. It seems there will be plenty of philosophies to choose from when organizations are going the select the platform(s) to support the multi-domain MDM journey.
Unfortunately the term “intelligent design” has a connotation in the U.S. that may result in passionate non-technical related arguments. But ignoring that concern for a moment, MDM is not an intelligent solution to begin with. MDM is an attempt to search for a singularity of data which does not exist. The solution reminds me of Frankenstein. An entity made up of disparate parts sewn together to resemble some form that is awkward, uncoordinated and beastly. The exact opposite of “intelligent design”.
The primary reason for MDM’s existence is as a result of an inadequate design to begin with. Imposing yet another design upon a flawed design is at best limited and at worst creates more complexity than the problem to begin with. It appears that we are trying to write our way into a solution but in practice MDM is nothing more than trying to create an ERP solution but without the business applications software. MDM was created out of ERP. But the creation is anything but intelligent.
Thanks for commenting Richard. Maybe we can have a passionate technical discussion.
I disagree with you about MDM in practice. I do think MDM is a concept with the capability of solving a whole lot of issues. Many organizations struggle with data silos and master data silos are the worst. We seldom see monolithic solutions encompassing all business requirements in an enterprise, and even a monolithic platform as SAP has a special MDM component. Many enterprises running SAP also has a lot of other applications with master data inside, where it is good for business to have a MDM platform inside or outside SAP.
Data quality, the theme of this blog, is probably the best reason for having a MDM platform. We need a single sustainable structure where we can store our data quality improvement results in the complexity required for all business purposes.