During the day I exchanged a dialog John Radcliffe today regarding the recent flurry of acquisitions in the MDM market. Rather tongue-in-check I suggested that “MDM as we know it is dead, as of today” and that “we will soon have to invent a new name to describe where all this is headed – how about MDM 2.0?”
I was listening to a vendor today, in the MDM market, and this is what I heard: “MDM is often surrounded by data quality, data integration, and other things” and “as such, we need a new name to describe all these things coming together”.
It is my conclusion that this vendor assumes that the discipline of MDM does NOT require a combination of data integrity, data quality, entity resolution, matching, data integration, governance, metrics and analysis, across ranges of implementation styles, for all manner of master data types/domains. Apparently some folks think that MDM is less than this. The vendor wants a new term to denote all the great things that they do – which is not, apparently, MDM.
John and I called it correctly, 4 hours earlier in the day, but I thought we were joking. Who would have guessed that the joke was on us? Worse, I bet someone goes for “data governance”.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
12 Comments
Andrew, what a coincidence, several colleagues and I were discussing the very same thing this morning. The recent days have changed the playing field, and we stated \MDM is dead.\
What we came to realize is that there is a fear that MDM will be a method to products vs a method to business goals. But we realize that will be a few years off, and the market / requirements / business will change in the mean time.
Data Governance… funny you bring that up… is that where we are going now ? Will that be safe for a while ? I am looking forward to your insight to this new playing field. Thanks for all your posts, really enjoying the last few.
Andrew, very happy to see this discussion, can’t agree more.
– Data Governance is all about giving back control to business lines on their shared data. They need new “active” capabilities for managing models, rules, hierarchies, workflows, versions, rights… not only a central repository to store it
– Data Integration & Quality are complementary to Data Governance but already there for many other purposes. Why reinventing the wheel on that?
We look forward to seeing a DG Magic Quadrant soon!
Hi Andrew,
Very topical.
As Data Professionals, we understand the importance of a “Business Glossary of terms” that explains terms in a business context, and explains the relationship between terms.
To my knowledge, we have no definitive “Business Glossary of terms” covering terms such as: MDM, data integrity, data quality, entity resolution, data matching, data integration, data governance, data metrics, data analysis, etc. etc.
The absence of a shared understanding of terms makes it difficult for “meaningful” debate to take place. It also makes interaction with prospective clients difficult.
My personal opinion is that “Data Governance” should “govern” all of the other data management processes.
I would welcome your opinion on this.
Rgds Ken
I think we will see the same moves as in CRM. Moving from Sales Information Systems, Sales Force Automation etc. etc. to a more overall an generic term as CRM.
In the case of MDM for Customer Data, Customer Data Integration etc. I prefer Customer Data Management. PIM is still something different in my opinion.
Hi Ramon,
Thanks for the post. I wanted to understand how you thought “CRM” evolved…maybe or maybe not from its constituent parts, but the more interesting dialog would be to focus on PIM. Could you please explain why you think Product Information Management is different to MDM of Product Data, or “applying MDM practices to product data”? This might be a fun and interesting exploration. Thanks.
Andrew
Ken,
Thanks for the post. I noted your “opinion is that “Data Governance” should “govern” all of the other data management processes.” I would tend to agree with this as stated. However, I wrote the other day that “governance” and even “data governance” is not overly meaningful.
When I hear a user admit, “I need governance” this is not meaningful since there is no context. What needs governing? “Data governance” implies governance of “data” but what on earth is “data”? Ask 3 analysts that question and you’ll go through 90 minutes and identify 26 different types of “data”.
So I agree with your point, but I would qualify it further. I think I have an understanding of what is implied with “Master Data Governance” or “Governance of Master Data”. And in our definition of MDM (as a discipline), such governance was always included. In fact, some would argue this is one of the main reasons (the lack of master data governance) that led to the formation of MDM.
Thank you for your comments in “Something beyond MDM is coming your way – would MDM 2.0 fly?” and starting the discussion to expand the definition of MDM to include data integrity, data quality, entity resolution, matching, data integration, governance, metrics and analysis. The topics discussed should also include work flow (management of data and analysts), translation management, data structuring, data profiling, duplication removal, data change management, verification contact management, etc.
The MDM and PIM software industry needs to take a step back to understand actual day to day business requirements of data management to achieve Master Data Quality. Lesson one is that data is created and supplied by many sources in many different formats at various quality levels. Data is created by engineering, submitted by integrators, manufacturers and suppliers. To add to the complexity of the information flow, data is introduced into businesses systems in different departments (engineering or purchasing or maybe plant from maintenance) with different data requirements to meet the needs of that job function. Now the next dynamic is mashing new data to existing legacy data in a number of systems to ensure no duplicates are created, managing obsolete / recommended use and functional equivalents. The old philosophies of a PIM or MDM software to “hold, provide search functionality and maybe a shopping cart” isn’t going to meet the true requirements of the new definitions of Master Data Management.
To meet the new definitions the MDM or PIM software needs to provide horse power to electronically and intelligently processing data to identify exceptions for manual intervention by an analyst. Data should be processed one time to ensure that the data record will be enriched to meet the requirements of the enterprise and then the record is moved to a maintenance program (managed also by the MDM or PIM software). The processing of data needs to be efficient and cost effective, from my perspective the cost of data management should be covered by the cost saving achieved by MDM management.
I look forward to the discussions as the definition of MDM is expanded to include data quality, data governance, data provenience as the software industry provides the intelligence, functionality and business processes to cleanse, enrich and management data for my client to ensure their ability to make confident business decisions based on data integrity and accuracy.
Here is to the future of PIM and MDM!
Andrew,
Your post is very relevant. As system integrator we still fight every day against approaches envisaging MDM as a pure IT effort.
Even if I would not envisage MDM without data quality and data governance, I would not merge these concepts. I would go for a view where data quality and data governance are the backbone of the effort to put information at the heart of the business. This is where you will have to manage this huge challenge to change the habits, to build your stewardship network, to communicate the “What’s in it for me” to the organization, etc.
Once these foundations are in place, any information management initiative will share fundamentals – like enterprise business definitions, a data stewards network, etc. – and will quickly deliver added value. MDM for example is basically an answer to a need for transversal business processes across your organization and cannot be possible without a foundation of quality information.
We apply the same principle to the BI domain (having the same goal as MDM of a trusted single version of the truth but on decisional topics) with the introduction of the BICC having as key basis, data quality and data governance.
Andrew,
I can remember vivid discussions with professors in 1990 (during my study) about “how should we name direct marketing”. Database(d) (driven) marketing, one-on-one marketing, customer marketing, relationship marketing etc. A few years later we called it customer-based marketing management. We wanted to get rid of technical terms and included management to emphasize the role of the business. Vendors in that time used all different terms for their solutions. It took a few years before we ended up with CRM as a container definition.
CDI and PIM can indeed be solved with the same solution and many technologies, algorithms can be shared. But I still like to think SAP ERP is something different from SAP CRM. When our economies and industries make it possible to serve each customer uniquely than it will come together. Until than I think it is easier to make a distinction between PIM and CDI. One of the reasons is that the business users are completely different from each other.
Regards,
Ramon
Hi Andrew,
Your question above about MDM for Product vs. PIM is one that has always been a good topic for me to discuss. I’ve found that pure-play MDM products, or CDI products turned into PIM products aren’t quite the same as PIM, and are missing some things. Meanwhile, I would also contend you there are probably good PIM products available that don’t have full MDM functionality (and certainly not generic MDM functionality).
This is not the right place to go into things at length, but one example might help. Within PIM, there is a need to be able to easily manage product information for large numbers of products (10s of thousands, to millions at least). This requires tools for business users to do so efficiently. Tools to categorize products into a hierarchy and define attributes that are category specific. Then tools to easily manage the data via inheritance or mass editing. For those not familiar with PIM, think of this: hammers may need an attribute to describe their handle type (wood, fiberglass, steel, etc.). Power drills will not have that attribute, but may instead need voltage and horsepower attributes. And if you’re managing thousands of these things, you certainly don’t want to have to make changes by manually editing each one.
That’s just one example — but it also underscores an important point. You could build a fantastic generic MDM tool that has no user interface at all for editing data (only for inspecting, quality ranking, de-duplicating, selecting best sources, etc.). Not true in the PIM world.
Regards,
Robert
Robert,
Thanks for the replay. I would agree that “PIM” vendors have struggled to meet the needs of “CDI” and equally “CDI” vendors have struggled to meet the needs of PIM. In fact we maintain two Magic Quadrants, one for the MDM of Product Data domain, and the other MDM of Customer Data domain. For some of the reasons you site, these two market segments out to be “MDM of ‘thing’” and “MDM of ‘party’” but that is not as impactful to the reader.
There are differences, and there are also similarities, in the needs of the two domain (or, at the thing and party level, provinces). Inheritance, common in data modeling for complex products, sometimes pops up in changes to sales territories, common in “analytical MDM”. While “PIM” is used to managing thousands of records, and thousands of attributes, “CDI” was used to handling large volumes of transactions for reasonably simple (by comparison) objects. Though CDI get’s pretty complicated in financial services sector… Then there are other “generalist” that call themselves “MDM” vendors (and they can model almost anything) but they rarely have any deep knowledge at the industry level; very important when you want ot know what one should do, and what to avoid. In days long gone I used to argue for “five levels of multi-level forecasting” because it worked, as a means to automatically improving the accuracy of a forecast, in thousands of implementations. That “best practice” would sometimes get lost to user who fell for the competing vendors who offered “unlimited levels of aggregation and disaggregation”. Just because something is possible does make it better.
I don’t see many “MDM tools” without a user interface these days. I can’t quite imaging “governing” anything without some screen presenting the status of the thing that is being governed. Look at all the CDI tools that now has a user interface. And look at the PIM vendors that moved (not all, yet) to secure access to party matching, merging and entity resolution capability. Sings of a market maturing, and elements converging.
So I agree with your opening point, CDI/MDM does not make a natural fit for PIM; just as PIM/MDM would not be a natural fit for CDI. However, it seems clear that CDI and PIM remain different sides to the came coin.
Andrew,
After the recent string of acquisitions I created a post on LinkedIn with the title “Is MDM Dead?”. This of course was a light-hearted statement and anyone who as worked with me knows how much I am an advocate for MDM as a component of a information lifecycle process. Although MDM contains the word “Management” up until very recent it was predominately software.
I do believe that MDM 2.0 will fly and recent acquisitions only justify that. We are seeing MDM software being integrated into “Data Quality” organizations which is a great indicator as to where technical solutions are now going.
The challenge I have traditionally encountered the analyst community (most but not all) is that analysis of Consulting organizations have always been evaluated as “Systems Integrators”. I am hoping that we now see a focus on organizations that focus on the business alignment, process expertise, and the alignment of information assets to improve business performance independent of firms that simply implement technologies. Two very different, distinct skill sets and should be looked at as such. I also believe that expertise will need to be evaluated by industry as understanding core processes and alignment to the processes to operationalize stewardship will be the greatest path to mitigate risk and drive adoption.
Just my 2 cents.
Chris