Continue in 2 seconds

Managed Meta Data Environment: A Complete Walk-Through, Part 1

  • April 01 2004, 1:00am EST

Author's Note: This column begins an eight-part series adapted from the book Universal Meta Data Models by David Marco and Michael Jennings (John Wiley & Sons).

Almost every corporation and government agency has already built, is in the process of building or is looking to build a managed meta data environment (MME). Many organizations, however, are making fundamental mistakes. An enterprise may build many meta data repositories (or "islands of meta data") that are not linked together and, as a result, do not provide as much value (see sidebar).

Let's take a quick meta data management quiz. What is the most common form of meta data architecture? It is likely that most of you will answer centralized; but the real answer is "bad architecture." Most meta data repository architectures are built the same way data warehouse architectures were built: badly. The data warehouse architecture issue resulted in many Global 2000 companies rebuilding their data warehousing applications, sometimes from the ground up. Many of the meta data repositories being built or already in use need to be completely rebuilt.

The goal of this eight-part series is to ensure that your MME's architecture is constructed on a rock solid foundation that provides your organization with a significant advantage over those with poorly architected MMEs. During this series, I will present the complete MME architecture and walk through, in detail, each of the six major components and the sustainment of the MME.

MME Overview

The managed meta data environment represents the architectural components, people and processes that are required to properly and systematically gather, retain and disseminate meta data throughout the enterprise. The MME encapsulates the concepts of meta data repositories, catalogs, data dictionaries and any other term that people use to refer to the systematic management of meta data. Some people mistakenly describe an MME as a data warehouse for meta data. In actuality, an MME is an operational system and, as such, is architected in a vastly different manner than a data warehouse.

Companies that are looking to truly and efficiently manage meta data from an enterprise perspective need a fully functional MME. It is important to note that a company should not try to store all of their meta data in an MME, just as the company would not try to store all of their data in a data warehouse. Without the MME's components, it is very difficult to effectively manage meta data in a large organization. The six components of the MME, shown in Figure 1 on page 51, are: meta data sourcing layer, meta data integration layer, meta data repository, meta data management layer, meta data marts and meta data delivery layer.

Figure 1: Managed Meta Data Environment

The MME can be used in either the centralized, decentralized or distributed architecture approaches. Centralized architecture offers a single, uniform and consistent meta model that mandates the schema for defining and organizing the varied meta data stored in a global meta data repository. This allows for a consolidated approach to administering and sharing meta data across the enterprise. Decentralized architecture creates a uniform and consistent meta model that mandates the schema for defining and organizing a global subset of meta data to be stored in a global meta data repository and in the designated shared meta data elements that appear in local meta data repositories. All meta data that is shared and reused among the various local repositories must first go through the global repository; however, sharing and access to the local meta data are independent of the global repository. Distributed architecture includes several disjointed and autonomous meta data repositories that have their own meta models to dictate their internal meta data content and organization, with each repository solely responsible for the sharing and administration of its meta data. The global meta data repository will not hold meta data that appears in the local repositories; instead, it will have pointers to the meta data in the local repositories and meta data on how to access it (see Chapter 7 of Building and Managing the Meta Data Repository for a more detailed walk-through of these approaches). At EWSolutions, we have built MMEs that use each of these three architectural approaches, and some implementations use combinations of these techniques in one MME.

Next month, I will begin my detailed walk-through of each of the six MME components, starting with the meta data sourcing layer.

Where's My Meta Data Architecture?

AT EWSOLUTIONS, ONE OF OUR CLIENTS is a large pharmaceutical company. Because knowledge is the lifeblood of any pharmaceutical company, these types of firms tend to have very large meta data requirements and staffs. Our client decided to hold a "Meta Data Day," and they asked me to give a keynote address to begin the day. Between 60 and 80 people attended their "Meta Data Day."

A series of workshops followed the keynote address. We counted four separate meta data repositories in production and three other separate new meta data repository initiatives starting -- a classic "islands of meta data" problem. This is not an approach that leads to long-term positive results, as much of the most valuable meta data functionality will come from the relationships that the meta data has with itself. For example, it is highly valuable to view a physical column name (technical meta data) and then drill across to the business definition (business meta data) of that physical column name.

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