T E R R Y     M 0 R I A R T Y

What you consider metadata depends on how advanced your business

What Is Metadata?

July, 1997

With the emergence of the data warehouse as a primary decisionsupport application, metadata has taken on new importance within the business community. Metadata is now considered as much a corporate resource as the business data it describes. It's nice to be responsible for the latest industry buzzword, but few people seem to agree on exactly what metadata is.

Sure, you get the same initial answer from everyone: Metadata is "data about data." This definition has a nice Zen quality that makes it a great slogan, but it doesn't tell you much. If you held a piece of data up against this definition, you probably couldn't determine if that data passed the test.

So when you probe to determine what people really consider to be metadata, you'll probably find many different interpretations. I believe that these different interpretations are related to how advanced an organization is within the "knowledge management" evolutionary hierarchy (see Figure 1).

Organizations at the lowest level of the hierarchy manage raw data. More advanced organizations are able to manage their information resources at the Information, Knowledge, or Wisdom level. To determine where your organization is in respect to this hierarchy, you must first understand these four levels.

Sand provides a helpful analogy for describing the differences between these levels (I've borrowed this idea from Gary Rush of MG Systems, who uses an hourglass analogy in his workshops for facilitation session leaders):

The Data Level. Consider sand in its natural state. When dry, a single grain tends to exist independently of all its other brethren grains. It is very light and can easily be blown about on a windy day. But when wet, its behavior is completely different. It clings to anything it touches and bonds with neighboring grains of sand to create an immovable object, impervious to the effects of the wind.

In this natural state, sand is comparable to the data level of the knowledge management hierarchy. For the most part, this level is very similar to the data column in the Zachman Information Systems Architecture (ISA) framework.

The Information Level. If sand is placed in an hourglass, it assumes a new role: It becomes a meaningful component of a time-measurement system. The hourglass system provides a context for interpreting the sand that was impossible in the sand's natural state. The hourglass thus represents the information level of the knowledge management hierarchy, in which all components are combined into a system to achieve some objective. At the information level, we focus on the relationships between all system components and the individual roles they assume in the system. Likewise, we focus on the events the system must respond to and the processes it performs to respond to those events and to keep itself in a steady state, including the order in which it carries out those processes. Based on the context, the same raw material can behave differently: The properties of sand important to an hourglass system are different from the properties that make sand useful for glass making. The information level corresponds to the data, process, network, people, and event columns in the ISA framework.

The Knowledge Level. Anyone observing the hourglass system may have a difficult time understanding its behavior if they don't know its governing rules. Without a rule book that describes the hourglass's purpose as a time-measuring device, explains how to activate the hourglass, and reveals what time unit is being measured, the uninitiated would find it hard to understand the hourglass system.

In our hourglass analogy, a "knowledgeable person" is someone who has internalized the informational context that represents the hourglass time-measurement system and the rules dictating its behavior. An organization that has evolved to the point at which it can explicitly state the business rules governing its behavior has evolved to the knowledge level of the knowledge management hierarchy. This level encompasses the entire ISA framework by addressing the Rules column.

The Wisdom Level. An organization achieves the most advanced level of the knowledge management hierarchy when it actively monitors its system to ensure that it behaves as planned. Such an organization can detect and diagnose any abnormal system behavior.

In our hourglass analogy, a "wise person" would, for example, detect that the sand is not falling from one chamber to the next in the prescribed time period. That person might determine that some small amount of moisture had seeped into the chambers and caused the sand to cling together. A solution is then sought: Either fix the hourglass, throw it away and get a new one, or find a more reliable time-measurement device.

To achieve the wisdom level, business rules must be managed in a manner that allows them to be monitored and assessed. An organization must also have captured the metrics to monitor the behavior of the system against its business rules. Furthermore, the organization must maintain business rules in a format that will allow changes to a rule to affect business behavior immediately. (See Barbara von Halle's column this month on the subject, page 15.) Text is not the best format for maintaining business rules for this purpose. However, the ability to generate the organizations business rules in natural-language form is essential.

THE METADATA QUESTION

As I wrote at the beginning of this column, what you consider to be metadata can vary based on how advanced your organization is in the knowledge management hierarchy. (Table 1 shows how metadata's meaning changes from level to level.) An organization evolves through the hierarchy as it assumes the responsibility of actively managing how its business rules are implemented in its application portfolio. As part of this evolution, it moves from business rules that are primarily stated in text (within policy and procedure manuals, product specification and pricing catalogs, and business information requirements specifications) to a format that is able to impact the behavior of the business systems directly. To make this move, an organization must strengthen the fink between the business view of its business rules and the mechanisms used to enforce those rules in the application portfolio.

At the data level, this strong correlation between the business rules expressed through the data model and database components exists. Nearly every CASE tool that supports data modeling can generate database components from the data model's metadata. Many can also generate reasonable natural-language statements that represent the business rules asserted by the data model.

The same level of dependency has not yet been achieved for the other levels of the knowledge management hierarchy. However, an architecture is emerging to provide support for business rules in a separate engine that is independent of the application code. As soon as the industry creates infrastructure software that cooperates with program code and DBMSs to provide a business rule management environment, organizations should be able to achieve the knowledge level.

Many have asked me how business rules analysis is different from what we traditionally represent in data models. I agree that data modeling is a useful technique for discovering and analyzing business rules. However, business rules analysis involves much more than just data modeling. Several proposed business rule classification schemes took very similar to what we routinely capture as metadata in support of a data model. However, the focus of the classification scheme is on business rules, which means that the text stating these rules is far more significant than the text adendums to a data model. Each category in these classification schemes presents tool developers with an opportunity to provide the missing link between a business rule's specification and the executable support for that business rule.

When each business rule category becomes the basis of software that uses the business rule documentation to generate an application portfolio component to enforce that statement, what we have formerly expressed as metadata will be used to generate application components. At that time-when metadata is routinely used to generate executable business rules-the definition of metadata will be "the representation of business rule statements according to a classification scheme that can be readily transformed into business information systems."

REFERENCE

1. Zachman, J. "Enterprise Architecture: The Issue of the Century." Database Programming &Design, 10(3): 44-53, March 1997.