Andrew White

I spoke with an end user the other day that had a pretty forward looking strategy as it related to MDM, and specifically MDM of Product Data.  When we talk about MDM of Product Data, there are assumptions that we all make – and these might be different.  Is MDM of Product Data a sell-side phenomenon?  Is this a buy-side phenomenon?  Is this an enterprise wide (buy and sell side) view?  The reality is “all of the above” until and if we get more specific.  The reality is that initial MDM work in this area assumed all, yet mostly focused on sell-side of (again mostly) finished products.

Over the last 5 or 6 years this focus has broadened in scope and has since spawned other drill down topics, such s Procurement MDM which has, itself, split into MDM of Supplier data and MDM of Purchased Part.  Holistically though, MDM of Product Data generally means mastery of “thing”.  Thing is a kind of ‘province’ in that most “things” have common characteristics or challenges; and characteristics and challenges across ‘provinces’ are not similar (think customer/supplier master data).

Well this forward looking user was just starting to roll out an MDM application (single solution, single vendor) for both buy-side product data as well as sell-side product data.  I say this is forward looking because to date most users, if they have gone this far, have assumed that a different solution and possibly different vendor, are needed for each.  Sell-side MDM is much more mature – the mastery of the data was separated from the business applications that created – and consumed the data – 6 or more years ago.  For buy-side, the procurement and spend data management vendors have not yet “let go” the data and so users on the buy side assume that procurement vendors and spend data management vendors are also providers of MDM of purchased part solutions.  Like sell side, the separation of the data and the application will take place – it is just taking a long time.

So this client has taken a leap of faith – they hope several things:

• The MDM vendor can in fact cop with the complexity of requirements for both buy and sell side
• The business applications and analytics solutions, used by business users, to guide selling and buying decisions, will easily integrated with emergent MDM infrastructure
• IT can create a new discipline that, when needed to develop and deploy new business applications and analytics, they do NOT develop or deploy them in the MDM application itself, but as part of the business application and analytics layer.

When users ask for more analytics and business process support the natural and obvious choice will be to “add it to the MDM application”.  After all (the logic will run), that is where the really good clean data resides.  But in adding business application and analytic logic to the MDM infrastructure layer, IT would be reverting back to what it has been doing for the last 20 years – that created the mess in the first place that led to the conclusion that some change in “Integration” needs to take place!

There is a trade-off that emerges: MDM leads to the separation of master data from business application/intelligence.  IT is shifting from 20 years of vertical silos (application plus data) to a new framework of horizontal services (application, analysis, information management).   In the process, and it is a long process to get from a) to b), the IT stack does get more complicated.  So short term costs could increase, flexibility may not accrue immediately, and complexity may increase also.  The pressure to get MDM firmly established for all important master data objects needs to be kept up else the business will not see the benefits and the risk is that MDM will fall from favor for a traditional (silod) business-as-usual approach.

So it will be an interesting time for this user: Great vision, great strategy, hopefully not too far ahead of where the vendors can meet the user needs.  I will be watching very closely – as will many of you, I know.