Andrew White

There are at least three sets of requirements that exist across two use cases for MDM that, despite showing similarities, might derail how MDM is evolving.  In operational MDM users evaluate the impact on sales regions and territories of product and service sales and performance.  This “hierarchy” data links customers to locations and regions, and organizations and used by sales and marketing users.  Also, a different “hierarchy” set of data is used by sales, marketing, and product managers to evaluate the same data but in terms of products, categories, and brands.  In the analytical MDM use case financial users use similar data but often times for forward looking, “what if” analysis.  Also these users do evaluations of financial statements – what happens if this acquisition is executed and two businesses are merged> 

In both use cases, the need to provide business users with analytics and analysis on master data, or on evaluations of changes to that master data, is common.  The market (i.e. vendors) addressing the needs of users across both use cases have so far brought to market solutions that tightly embed business analytics, and analysis capability, with (master) data management capabilities.  This tight coupling is reflective of how business applications have evolved over the last 20 years; and it is for this reason that this ongoing development is dangerous to long term success of MDM.

The issue is that MDM is not a business application per se, but it requires a business application that is used to operationalize and support the MDM process.  These MDM processes support numerous business processes, actions and initiatives.  MDM has come about because IT realized that these services need to be independent of business processes and applications – and it is this separation of the master data from the application that crated/needs it that makes MDM work.  We are coming from an era where data and application were designed, built and deployed together, to a new era based on layers of services.  

When Analytics IN MDM is NOT Needed

The tight embedding of business user oriented “what if” capability that models changes in master data, in a business context (as opposed to a purely MDM context) is dangerous to MDM.  This “requirement” has caused vendors to develop business application functionality ‘on top’ of MDM solutions.  This is what we need to get away from!

If we keep designing and developing business application functionality on the actual MDM solutions we will perpetuate the architecture of the last 20 years. And it is this architecture of the last 20 years that has caused the problem that MDM was conceived of to resolve.  The “what if” capability is needed by business users, but it should be designed and built as business applications that consume master data via services, such that the MDM processes can operate as they were meant to – independent of all consuming systems.

When Analytics ON Master Data is Needed

This is not to say that analytics on master data, as part of the MDM discipline, is not needed.  This is a very different statement.  There is a great need for applying analytics and metrics within the context of MDM.  This is what supports the active governance of the process, to ensure that MDM is doing what it is supposed to be doing.  However, most vendors are pretty poor at this.  Most address metrics as if it was the output from a batch routine for loading or processing data.  Most vendors do this because this is how most data quality has been executed in the past.  This is a start, but this is not enough (see next blow).

How has this Risk to MDM Evolved?

Ever since MDM got started there have been times when users have pushed vendors to develop their technology to the point where MDM becomes a lot like a business application – one that does not actually do only what MDM is supposed to do.  In the MDM of Customer Data domain, several early MDM vendors were asked to develop marketing analytics that describe conditions and status of customer interactions and relationships.  In the MDM of Product data domain, several early MDM vendors were asked by their customers to develop workflow engines that supported the creation of product data in one place, rather than across the myriad systems that were used before hand. 

More recently, as the collective view of MDM evolved, and “analytical MDM” as a distinct use case emerged, it was clear that this pattern was repeated in other areas.  In the example given at the start of this blog, financial systems merged “what if” analysis of pending changes to hierarchies (master data) that might signal a change in how corporate reports roll up the transactional data.

The generalized observation is this: as soon as you put into the hands of the business user good, clean, validated master data, they start to ask really good questions that business applications vendors and designers have been trying to answer for years – and were generally unable since the source of the master data needed was outside the purview of those same business applications.

Now there is risk in “doing what customers ask”.  Some authors have said, “your customers are the last place to look for vision” since they are highly motivated NOT to undermine the investment they just made in your technology.  As such, customers should NOT be listened too for ideas for step-change innovation; only for incremental improvements.  So are these examples, of customers driving MDM to be more “business application-like” examples of step-change innovation of where MDM should evolve too?  Or are they short term, erratic, incremental developments?   I think the latter – and a very dangerous latter too.  What do you think?  Care to disagree?  Why?

1 Comment »

Category: Analytical MDM Hierarchy Management Operational MDM     Tags:

Share