It came to me, as I wrote a response to a client inquiry: the business case for master data management (MDM) is very different to the business case for application data management (ADM). In testing this thought with my colleagues Saul Judah, Bill O’Kane and Michael Moran, we came up with the following. First, let’s define the two for the purposes of this blog:
- Master Data Management (hubs) – those designed to be as flexible as possible in order to accommodate semantic consistency of core (master) data shared between any number of business applications.
- Application Data Management (hubs) – those designed to manage semantic consistency of a wider range of data for a specific application or suite of applications such that some local optimization is achieved.
These definitions, not precise or politically correct, are taken from my recent blog, “A Curious Development in Master Data Management (MDM) Land” two weeks ago. A major difference in the design goals of the two lead to a conclusion and a finding. The difference I want to call out is the environment in which the two – MDM and ADM solutions – are targeted. For MDM the environment is heterogeneous and also unknown: by definition you won’t know which business applications will come, or go, over time. With the latter – ADM – the environment is already known.
The conclusion then is that in both cases optimization of the solution design can take place, but in different ways. MDM needs to be really, really flexible in terms of data model design, and its ability to support flexible data modeling. ADM needs to be perfectly tuned to the known data model to which it is being pointed at. The finding is that vendors that sport such solutions have followed different patterns: solutions designed from the ground up to “be good at MDM” either have no pre-existing data model, or they have a very flexible data modeling capability and any number of industry templates that demonstrate that capability. Solutions designed “to be good at ADM” have a specific data model that happens to look very similar – if not the same – to the one offered by the target application or suite.
An adjunct requirement that also differs between MDM and ADM is that of integration. Similar to the need for flexibility with respect to data modeling, the unknowns within the application environment demands flexibility with respect to integration for MDM. Solutions require the ability to readily integrate to a variety of systems, not all of which will be known at time of implementation. ADM on the other hand has specific and known integration requirements. The solutions may not prove as flexible in breadth or capability as and when integration requirements change over time.
The final consideration: can you use an ADM to ‘do’ MDM? Yes, of course it is possible, but why would you start from that point? The data model, and the data modeling capability, are not likely tuned for neutrality or utmost flexibility – since that is not needed “to be good at ADM”. So this then leads to the business case question – how does it differ, given these conditions?
For MDM the business case does not exist in isolation to a business case for a set of business outcomes or processes (and supporting apps) that need to change/improve with the implementation of MDM. This your sales and marketing program, encompassing a CRM and e-Commerce application stack, has a business case. You can implement same with, or without, an MDM element. The costs will be different – so too the benefits. So the MDM business case is therefore part of the CRM/e-commerce business case. And note – you also assume that those applications – CRM and e-Commerce, provide the tools necessary to help end-users manage all the other data in those applications; MDM helps manage the shared master data between them.
Additionally MDM has some follow-on benefit in that it can be extended to support other business processes/apps. Thus there is ongoing synergy with an MDM strategy.
For ADM the business case is different. The business case is tied to the better use and management of information within a specific application. Thus we have together implemented a whole lot of business applications over the years that are pretty crummy at achieving this. In fact, some users have baulked at paying software vendors for new tools to support ADM given that those users assumed the application they licensed or subscribed to have this capability as a matter of course. Who would really license an application that didn’t? It would like buying a motor car that didn’t have a dashboard. So the business case for ADM is actually part of the same business case for the specific application – it should never have been separate or separated. There is no re-use and so there is no synergy with other data or other business applications: each one should sport its own level of support for ADM. Only MDM spans the shared data between those applications.
The split in focus and role of MDM and ADM should not seem pedantic. I think it sits at the heart of the next wave of innovation in terms of operational information governance: how we successfully exploit only the important information to maximize our collective business outcomes.