The Gartner Master Data Management conference is one of the more popular activities for those working in this space: customer discussions, analyst opinions and invaluable backroom and between-meeting conversations abound. But often, the most valuable learnings come from the discussions that occur during and after the presentations.

This year was no different.

The one area that reflected the diversity of content between analyst remarks and between-meeting discussions was the ‘Next Level of MDM’.

On the one hand, the presentations consistently referred to multi-domain MDM as this next level. (Multi-domain MDM is the concept of a single MDM hub platform supporting the mastering of multiple subject areas).

On the other, attendee discussions were focused on expanding MDM to address the obstacles that most companies are experiencing in managing and deploying the exploding breadth and volume of data that exists within their companies.

I spend a fair amount of my time gathering customer views on data strategy and data management – and can therefore confirm alignment between what customers are saying, and the between-meetings chat at Gartner’s conference.

From interactions over the past few months, these are the most common directions anticipated for future MDM functions and capabilities:

• Data directory services

There’s no greater consumer of time than searching for data within the enterprise. It’s not uncommon for developers and end users to spend 40 percent of their time searching for the data they need to analyse or include in a new application (and that reflects the existence of data marts, reporting tools, data warehouses and analytic systems). While existing MDM products do an adequate job of providing details to the subject area master elements, they don’t support the other 90 percent of the elements contained across the company’s numerous operational and analytical systems. Expanding the MDM platform to track and identify (but not store) the various locations of additional subject area details would be invaluable.

• Centralised metadata

The motivation for MDM is to provide access to a subject area master record along with the details of the contributing sources. What folks really want is a single centralised location for metadata content. Developers and end-users are desperate to understand data origins, definitions, meanings and rules. Most MDM products contain those details for mastered elements; it makes sense to expand the MDM hub to support metadata services to store, retain and share metadata for all the elements associated with a subject area.

• A data provisioning platform

Since the MDM hub knows the various source systems where the subject area details reside, why not position the MDM hub to retrieve the data? To be fair, the idea isn’t to support query processing and joins, just data provisioning. If an application wants to retrieve all the descriptive details for a customer, why is database (or system) location and access details required? The MDM hub knows where the data is; let it go and retrieve the data and deliver it to the requestor.

• Centralised data security

Most IT organisations (and product vendors) realised, years ago, that implementing user access security for individual applications and systems was too cumbersome and problematic. Centralised application and system access control has been around to address this problem. Unfortunately, such a capability doesn’t exist for data. MDM hubs can already store and retain CRUD (create, read, update, delete) for their own purposes – why not centralise all data security within the MDM hub? Rather than every database and application rely upon their own data security method, centralise data level security details within the MDM hub.

• Supporting enterprise data services

Every MDM product relies on web services as an application interface mechanism. While the most visible services include subject area CRUD processing, most MDM hubs require the creation of numerous “lower level” services (data correction, value standardisation, database access, etc.) to address the breadth of functionality necessary for production deployment. These services should be positioned as enterprise-level data services for all IT systems. Unfortunately, most MDM products don’t include the necessary tools and functions to integrate into a larger SOA and enterprise data services paradigm.

While I won’t argue with the merits of multi-domain MDM – that can be saved for later – as the concept of multi-domain hubs has been discussed for nearly eight years and lots of folks have already implemented them.

There’s a lot more we can accomplish with MDM technology; we’ve only scratched the surface when it comes to simplifying data management and access for our IT and business user stakeholders. In the era of big data, third party data providers, hundreds of data sources and exploding data diversity and volume, maybe it’s time to evolve MDM to leverage its strengths to address bigger enterprise data problems.

Forget about multi-domain MDM for now. Instead, the next level of MDM should be about leveraging its strengths to address the data management obstacles that continue to steal 40 percent of everyone’s time.

ABOUT EVAN LEVY//

Evan Levy is VP Business Consulting at SAS