Last month I introduced the concentric model that places meta data about master data, the most valuable data for an enterprise, at the center. As we move from the center, the model addresses the other types of meta data in terms of priority. Second in importance is the data warehouse meta data, then the processes and transformations involved in moving data to and through a data warehouse, and finally the application meta data.

Thinking of meta data this way helps us understand the reach of different types of meta data. This is useful for developing a meta data approach that recognizes the different business value of different classes of meta data. Second, a clear mental model for meta data is especially important to offset the void left by meta data tools available today. These tools often create meta data for the purpose of enabling a specific tool, such as an ETL tool or a query tool. However, there is a need for the creation of meta data that provides comprehensive documentation of enterprise data. A meta data model ensures that enterprises focus their efforts on the subset of meta data with the biggest business value.

Let's begin with meta data about master data. Each enterprise needs to define what master data means for their particular needs and industry. Because this data usually relates to customers/clients, products and organizations/locations, it is the most ubiquitous data across an enterprise and is shared the most. Although master data meta data is relatively static and is most common across the greatest number of business units within an enterprise, it is the data that is the most difficult to define. In my work with clients, I often encounter situations where their master data has a different definition in every business unit that uses it. Yet it is this very disparity that makes master data the most valuable place to create business meta data. The investment in consensus building across the enterprise is usually justified by the value of common definitions to the enterprise.

It has long been a mantra of data administration that the entire enterprise should use the same definition for master data. However, during the development of data warehousing in the last decade, it became clear that this is not always true. Companies have many different definitions across the enterprise for basic concepts such as "customer," and these cannot always be reduced to a single definition. Some of the differences are important, after all.

Figure 1: Concentric Model of Enterprise Meta Data

The trick is to reduce the many disparate definitions to the smallest number of definitions that are acceptable to various business units, and then find ways to name and describe the differences so everyone clearly understands what those differences are and what they mean. To make that happen, master data meta data should reside in a primary meta data repository, with business names and rich business definitions, as well as sourcing information, system of record, timeliness, technical definitions and business rules. This information should be shared across tools and platforms.

Enterprises that have completed the development of meta data for master data should turn their attention to the development of meta data for data warehouse data. Data warehouses are likely to include both master data and event data (facts). Event data is likely to interest fewer business units than the master data, but event data is stored in a data warehouse because it holds value to multiple business units. Even though it is not as ubiquitous as master data, it is still valuable and interesting.

Process/EAI/ETL meta data defines the transformations and other business rules applied during processing, whether custom-coded logic or embedded in an ETL or EAI tool. This meta data brings value because it documents activity in data interfaces. For instance, ETL tools tend to create meta data to drive the transformations executed by the tool. In contrast, EAI tools are apt to be very weak at meta data creation and custom processes tend to ignore meta data. This is an area of concern to multiple business units because the data is changing as it is moved through the interface. Overall, this type of meta data interests fewer people and therefore resides in the third ring of the meta data model.

The meta data with the lowest value to the organization is that which is restricted to a single application. Comprehensive creation of this meta data has the benefit of helping accelerate application maintenance efforts. However, it also has the smallest population of fans: the application maintenance team for that application. As such, it is often documentation that can be developed when needed, instead of being developed just in case someone needs it.

In the end, this concentric model helps us prioritize meta data efforts. Next month we will address how the prioritizing can be done when the tool support for meta data efforts is insufficient for our needs.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access