At a purely technical level, there is a significant need for coordination required for overseeing and guiding the information management aspects of an enterprise initiative such as master data management (MDM). The political and organizational aspects of this coordination are addressed as part of the governance program that must accompany an MDM program. However, all aspects of the determination of need, planning, migration strategy, and future state require a clarified view of the information about the data that is used within the organization – its metadata.
It is easy for us to fall into the trap of referring to metadata by its industry accepted definition: “data about the data.” This relatively benign description does not provide the depth of understanding that adds value to the MDM deployment. Instead, the metadata associated with an enterprise master data set does more than just describe the size and types of each data element. It is the historically distributed application and data silos that are impacted by the variance in meaning and structure that necessitated MDM in the first place. Therefore, in order to develop a model, framework, and architecture that provide a unified view across these applications, there must be a control mechanism, or perhaps even a “clearinghouse” for unifying the view when possible, and determining when that unification is not possible.
In fact, the scale of metadata management needed for an enterprise migration differs from the relatively simple data dictionary-style repositories that support individual applications. Sizes and types are just the tip of the iceberg. Integration of records from different data sets can only be done when it is clear that the data elements have the same meaning, that their valid data domains are consistent and that the records represent similar or the same real-world entities. Not only that, there are more complex dependencies as well:
Do the client applications use the same entity types?
Do the different applications use different logical names for similar objects?
How is access for reading and writing data objects controlled?
There are also many other important variable aspects.
There is value in looking at a conceptual view of master metadata that starts with basic building blocks and grows to maintain comprehensive views of the information that is used to support the achievement of business objectives. The metadata stack described in this article is driven by business objectives from the top down and from the bottom up, and is intended to capture as much information as necessary to drive:
The analysis of enterprise data for the purpose of structural and semantic discovery;
The correspondence of meanings to data element types;
The determination of master data element types;
The models for master data object types;
The interaction models for applications touching master data;
The information usage scenarios for master data;
The data quality directives;
Access control and management;
The determination of core master services;
The determination of application-level master services; and
Business policy capture and correspondence to information policies.
We can look at seven levels of metadata that are critical to master data management, starting from the bottom up:
Business Definitions, which looks at the business terms used across the organization and the associated meanings;
Reference Metadata, which details data domains (both conceptual domains and corresponding value domains) as well as reference data and mappings between codes and values;
Data Element Metadata, focusing on data element definitions, structures, nomenclature, and determination of existence along a critical path of a processing stream;
Information Architecture, coagulating the representations of data elements into cohesive entity structures, how those structures reflect real-world objects, and how those objects interact within business processes;
Data Governance Management, which concentrates on the data rules governing data quality, data use, access control, and the protocols for rule observance (and processes for remediation of rule violations);
Service Metadata, which looks at the abstract functionality embedded and used by the applications, and the degree to which those functions can be described as stand-alone services, along with the mapping from service to client applications; and
Business Metadata, at the top of the stack, which captures the business policies driving application design and implementation, the corresponding information policies that drive the implementation decisions inherent in the lower levels of the stack, and the management and execution schemes for the business rules that embody both business and information policies.
Given this high-level description of a metadata stack, the challenge is to look at how these levels interact as part of an overall metadata management strategy. I keep thinking in terms of metadata as a “control panel,” since the cumulative knowledge embedded within the metadata management framework will ultimately contribute to the determination of the most appropriate methods for delivering a master data asset that is optimally suited to the organization.
