Michael Blechar

While those in most organizations I talk to want one comprehensive metadata management solution, they generally understand that the issues surrounded an enterprise-wide set of shared metadata is beyond their scope, funding and governance abilities to implement. Hence most metadata management efforts – especially initially – tend to focus on smaller-scoped domains like data warehousing, master data management or the publishing and management of software services in registries or repositories.

When it comes to selecting the most appropriate domain to “start on”, I find that organizations frequently do not consider which further “sub-scope” to go after, or the issues surrounding the source and integration of metadata for that sub-scope. Let me give an example.

Let’s say that we have selected master data management (MDM) as our primary scope of metadata management to address. First, we need to know which subset of the domain is to be addressed first. Is it general customer or product metadata or some other sub-domain of MDM? And, is it to document and manage all the metadata for that sub-domain (customer contracts, customers orders, etc) or just some subset of scope within that sub-domain (like customer name and address metadata to the exclusion of contracts and orders)?

While many (most?) organizations fail to consider this issue of scope, others are able to get to this level of detail when trying to make metadata management strategy decisions. But I would suggest there are two layers beneath this which can cause the metadata management effort to fail and need to be considered.

The first is sources of metadata. Metadata can come from a spectrum of sources (see The Eight Common Sources of Metadata*) ranging from well-defined and managed metadata residing in models and metadata repositories to what’s locked up in the heads of certain business users of IT personnel – or even worse, might not exist at all! So, before deciding on a metadata management effort for a given sub-domain like “customer orders”, it would be valuable to know if the metadata about that domain exists or not, and how difficult in terms of time, cost and availability it would be to support that domain versus another.

The second is related – integration. When the metadata resides in machine-readable format with a definition of that metadata it is more understandable and (re)usable then when it does not. The more the metadata definition is in the format of a standard which crosses technologies and domains, the more likely it is the be sharable. The more that there are pre-existing bridges, federation or consolidation across technologies for that metadata the more sharable it becomes (see Six Common Approaches to Metadata Federation and Consolidation*).

You might know the sources of metadata, but unless they can be shared across the technologies of the domain in which you are focused (i,.e. such as across a MDM or data warehousing suite of tools), the less valuable the metadata will be, and the more difficult the ability to manage governance risk and compliance, coordinate change and release management, etc.

Net: When deciding on your metadata management strategy you must, of course, be driven by business opportunities and threats. But to minimize the potential for failure to achieve metadata management objectives – and to make a fully informed decision on how the metadata management effort is going to move forward – also factor into your decisions the available and type of sources for the metadata and how those sources can or cannot be integrated through federation and consolidation.

*Available to Gartner clients or for a fee

1 Comment »

Category: Uncategorized     Tags:

Share

Tweet