John Singer

Summary: Part 1 examined the phenomena of meta data repositories, identifying common patterns of process and technology. Part 2 defines a strategy for successfully implementing an IT knowledge management program based on meta data repository concepts.

In Part 1 of this article, we explored the concepts of detail and diversity in meta data. We noted that meta data projects tend to cluster into three distinct groups based on their mix of meta data detail and diversity. These three use cases can be described as "control," "inform" and "plan."

The "control" use case typically involves an individual IT technical service provider group (e.g., DBA, security, network, systems management) working within its domain. Existing system management tools are leveraged as collectors of meta data for better control, reporting and analysis of the environment being managed. Data is captured at the most detail level possible; however, including only that meta data directly controlled by the technical domain (i.e., low diversity). Virtually every technical service department in your organization has a homegrown database to track and manage IT assets, yet none of them are integrated or even known outside their department. These efforts are typically run as system management improvement projects and not necessarily recognized as meta data projects at all. Unfortunately, these projects also represent the source system or the system of record for all other meta data related efforts.

They say what goes around comes around and this certainly applies to the meta data information repository. Over the last 25 years, each great evolution of information systems technology and best practices has bred the same set of issues and the invariable vendor response - the meta data repository (or some derivation). What is this problem that keeps recurring? Simply put, as newer technologies are used to develop systems, the increase in complexity breaks the system management status quo. The answer always involves storing information about the system components in a central place for analysis - i.e., the meta data repository. It hasn't always been called this, but nonetheless, the basic approach to solving IT management complexity is the same. We are now witnessing this event playing out once more, but I'm getting ahead of the story.

This article seeks to examine the phenomena of meta data repositories, identifying common patterns of process and technology. Despite what appears to be great similarities, differing IT constituencies and problem domains suggest that a one-size-fits-all solution approach will not work. Finally, in part 2, I will define a strategy for successfully implementing an IT knowledge management program based on meta data repository concepts.

In Part 1 of this article, we explored the concepts of detail and diversity in meta data. We noted that meta data projects tend to cluster into three distinct groups based on their mix of meta data detail and diversity. These three use cases can be described as "control," "inform" and "plan."

The "control" use case typically involves an individual IT technical service provider group (e.g., DBA, security, network, systems management) working within its domain. Existing system management tools are leveraged as collectors of meta data for better control, reporting and analysis of the environment being managed. Data is captured at the most detail level possible; however, including only that meta data directly controlled by the technical domain (i.e., low diversity). Virtually every technical service department in your organization has a homegrown database to track and manage IT assets, yet none of them are integrated or even known outside their department. These efforts are typically run as system management improvement projects and not necessarily recognized as meta data projects at all. Unfortunately, these projects also represent the source system or the system of record for all other meta data related efforts.