IT Brief Australia - Technology news for CIOs & IT decision-makers
Story image
Comparing master data management with application data management
Mon, 20th Mar 2017
FYI, this story is more than a year old

We are fast approaching our new Hype Cycle season and as we do, analysts 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 organisations 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 organisations 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 matter 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 recognised 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 organisations are confused over where to start what to do, when and for whom.

Also, MDM is not for every organisation, 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 realise 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.