DM Review Published in DM Review in March 2003.
Printed from

Meta Data & Knowledge Management: Data Stewardship Framework, Part 4

by David Marco

This is the fourth installment of an ongoing series on the data stewardship framework. In this month's installment, we will conclude our discussion on the most common data stewardship activities.

Data Stewardship Activities

Last month, I described three of the most common data stewardship activities: data domain values; data quality rules, validation and resolution; and business rules/security requirements.

This month, I will discuss business meta data definitions and technical data definitions.

Business Meta Data Definitions

One of the key tasks for the business stewards is to define the business meta data definitions for the attributes of a company. A couple of years ago, a friend of mine shared the following quote by Daniel Davenport: "The greatest problem in communication is the illusion that it has been accomplished."

I don't know if Mr. Davenport even knows what meta data means; however, his quote succinctly summarizes the need for business meta data definitions.

Typically it is wise to begin by having the business stewards define the main subject areas of their company. By subject areas, we mean the "nouns" of the corporation (e.g., customer, product, sale, policy, logistics, manufacturing, finance, marketing and sales). Typically, companies will have between 25 to 30 subject areas depending on their industry. Once your business stewards have defined their subject areas, each of these areas can be further drilled down (e.g., for product, your company may want to distinguish between the different lines of business or subsidiaries).

Some data elements will require calculation formulas of some sort. For example, your company may have a data attribute called "NET_REVENUE." NET_REVENUE may be calculated by subtracting "gross costs" from "gross revenues." Any calculation formulas will need to be included in the business meta data definitions.

Once the key data elements have been identified, the business stewards can begin writing meta data definitions on the attributes. The process for capturing these definitions needs to be supported by a meta data repository. The repository would have meta data tables that would have attributes to hold the business meta data definitions. In addition, a Web-based front end would be given to the business stewards to key-in the business meta data definitions. The repository would capture and track these meta data definitions historically. This historic tracking is accomplished by having "from" and "to" dates on each of the meta data records. Also, a meta data status code will be needed on each row of this meta data. This status code would show if the business meta data definition is "approved," "deleted" or "pending approval." This code is important because it is a poor policy to delete meta data rows.

When the first business meta data definitions are entered, it is common to mark them as "pending." This allows the business data stewards to gain consensus on these elements before moving their status to "approved."

Technical Meta Data Definitions

The technical stewards are responsible for creating the technical meta data definitions for the attributes of a company. It is important to understand that technical meta data definitions will fundamentally differ in form from business meta data definitions. As business meta data definitions are targeted to the business users, technical meta data definitions are targeted for an organization's IT staff. Therefore, it is perfectly acceptable to have SQL code and physical file/database locations included in the technical meta data definitions.

Usually, it is too much work to have the technical stewards list all of the physical attributes within the company. It is wise to begin by having the technical stewards list their key data attributes. Initially focusing on the core data attributes helps the IT department to have their technical meta data definitions on their most important data attributes. Once your technical stewards have defined these initial physical attributes, they can start working on the remaining attributes.

The process for capturing these technical data definitions will be a mirror image of the process to capture business meta data. In fact, the Web-based user screens should look very similar. Also, the same functionality that I described in the previous section (from and to dates, status codes, etc.) should also be included.

Once both the business and technical stewards define their meta data definitions, discrepancies will be discovered between the definitions in 100 percent of the situations. For example, the business stewards may define "product" as any product that a customer has purchased. The technical stewards may define "product" as a product that is marked as active. These two definitions are clearly different. In the business steward's definition, any product (active or inactive) that is currently on an open order for a customer would be valid. Obviously, the IT staff will want to work with the business users to repair these hidden system defects.

David Marco is an internationally recognized expert in the fields of enterprise architecture, data warehousing and business intelligence and is the world's foremost authority on meta data. He is the author of Universal Meta Data Models (Wiley, 2004) and Building and Managing the Meta Data Repository: A Full Life-Cycle Guide (Wiley, 2000). Marco has taught at the University of Chicago and DePaul University, and in 2004 he was selected to the prestigious Crain's Chicago Business "Top 40 Under 40."  He is the founder and president of Enterprise Warehousing Solutions, Inc., a GSA schedule and Chicago-headquartered strategic partner and systems integrator dedicated to providing companies and large government agencies with best-in-class business intelligence solutions using data warehousing and meta data repository technologies. He may be reached at (866) EWS-1100 or via e-mail at

Copyright 2005, SourceMedia and DM Review.