Gartner Blog Network


Comparing Master Data Management (MDM) with Application Data Management (ADM)

by Andrew White  |  March 19, 2017  |  Submit a Comment

We are fast approaching our new Hype Cycle season and as we do, analyst are want to explore what’s going on in the market around them.  One tactical nut that we are looking at, in the MDM team, concerns application data management.  First, let’s be clear what this is.

  • MDM is a business-led, IT-enabled discipline whereby an organizations seeks to govern and steward consistent master data across core business processes and systems.  In this case, to keep things simple, master data (is business metadata) are things like “customer” or “product” or “hierarchy” etc.
  • ADM is a business-led, IT-enabled discipline whereby an organizations seeks to govern and steward consistent application data for use in a specific application or suite of applications.  Application data in this case concerns all the data stored and used by that application or suite.

Off necessity application data will likely include a copy of some master data since it is the mater data that is used to link processes that span applications or suites – it’s the common semantic glue.  So far, so good.

From a technology point of view we have all seen a wide variety of implementations in support of MDM.  We have seen:

  • Standalone hubs that persist (master) data between and independent of apps
  • Standalone hubs that act as registry or pointers to where trusted data is persisted in applications for use by other applications

More recently we have seen at least two other interesting models:

  • Some vendors that license business applications that are actually “built on top” of MDM hubs – which support a kind of “MDM inside” capability.  We might refer to these business apps as being “MDM ready” in that the apps can integrate with other MDM offerings easily; equally those business apps help users manager the data in those business apps (what we call ADM)
  • Some clients then implement ADM with that application, and then “work there way” towards a full blown MDM program – sometimes with the MDM hub “inside” the original business app or perhaps as a separate app-independent hub

And finally we have some vendors develop solutions to help their clients just manage better the data in their business applications.  What you, as an end user, might have assumed was part of the business application all along!

So now we have a landscape to talk about MDM and the complexities of ADM alongside it.

ADM is basically very similar in concept to MDM in that both concern the governance of data for use.  MDM focuses on re-use across apps/process, ADM focuses on single use within an app or suite.  Now the complication:

  • When is a program called or recognized as MDM or ADM?  Is it a clear distinction?

Conceptually this is simple but reality complicates things.  Try these for size:

  • You license an ERP business suite that comes with its own data governance and stewardship solution that share one data model and persistence.  This is clearly an ADM implementation (as part of the ERP business suite)
  • You license an ERP system that comes with its own data governance and stewardship solution that share the same data model but the hub is deployed “outside” ERP as a standalone hub.  Again, as stated this is clearly ADM since the data being managed a the time is the ERP data for use in the ERP suite
  • But what if you then start to govern and steward a subset of that application data for use and consumption in another large, core business system?  Now that hub seems to support ADM for the original ERP system as well as MDM for a smaller set of data between ERP and some other app.

Now we are getting messy.  Is this important?

We feel that a distinction between MDM and non-MDM is very important but the “non MDM” seems to be a range of different programs that today we call ADM.  This is an important distinction since the effort, value and cost of an MDM program versus an ADM implementation are (or should be) vastly different.  MDM should lead to much higher value and require much higher effort and costs.  ADM should be less on all fronts but for the fact that some apps and suites of apps are more important than others.  So ADM for ERP is much more valuable than, say, ADM for WMS – all other things being equal.

We also need to make the distinction for the very simple reason that these programs are different and currently there is no name to separate them and so many organizations are confused over where to start what to do, when and for whom.

Also, MDM is not for every organization, at least not the same enterprise-wide MDM.  Smaller firms need “smaller” MDM.  But they may still need ADM.  And many of you, including me, are pretty upset when we realize that we have been implementing millions of apps for years only to discovery recently that they (the vendors) never really cared about how we would struggle to govern the data in them.

The distinction between MDM and ADM is important for many reasons and we are looking into this right now.  Do you have any thoughts?  Ideas?  We would love to hear them!

Category: application-data-management  master-data-management  

Andrew White
Research VP
8 years at Gartner
22 years IT industry

Andrew White is a research vice president and agenda manager for MDM and Analytics at Gartner. His main research focus is master data management (MDM) and the drill-down topic of creating the "single view of the product" using MDM of product data. He was co-chair… Read Full Bio




Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.