Meta Data Repository Redux, Part 2: Crafting the Enterprise IT Knowledge Management Strategy

InfoManagement Direct, April 2004

John Singer

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.

The "inform" use case has at its core the desire to inform and educate people outside of the immediate technical domain. This form of altruism is typically driven by user demand for greater understanding of IT systems in their own terminology. In this use case you see the introduction of higher level of abstractions to assist the user in navigating through the forest to find the particular tree of interest (e.g., naming application or data subject areas of interest). Data is also less detailed with emphasis on names of objects and their definitions but without the myriad other properties of interest to the technician. Diversity goes up in terms of the relationships that exist between classes of data. For example, data warehouse-oriented repositories place a huge emphasis on tracing relationships from OLAP report output back to original source system of data.

The "plan" use case takes the granularity and diversity dimension to the extreme. Diversity now includes linking meta data across the entire IT ecosystem, from technical infrastructure to business strategy. However, the meta data must be presented at a very abstract level (i.e., with little detail). The "plan" use case also introduces new classes of meta data that describe the business itself in terms of business processes and strategy. Notoriously difficult to develop and maintain, the business must define itself in terms that can be stored and analyzed without too much detail making it impossible to maintain. Finally, you see "non-traditional" meta data such as IT financial data and project management data added to the mix.

Crafting a successful enterprise IT knowledge management strategy clearly requires more than a good meta-model and repository. One must consider the various access patterns, use cases and meta data complexity. Figure 1 illustrates the architecture for bringing all this together.

Figure 1: IT Knowledge Management Architecture

Tool/Infrastructure Meta Data

We are drowning in a sea of meta data. Every tool and infrastructure component creates and stores meta data. However, it is typically not accessible or even understandable outside of the immediate team of domain experts (i.e., the tool/infrastructure owners). There is little if any interchange of this information between domain experts, yet the need for this information exists across the organization. The highest cost information exchange is the hallway conversation needed to communicate across domain expert boundaries.

The obvious place to start is with existing tool and infrastructure meta data sources. The starting point for a more transparent IT organization is with the technical service providers who, on a day-to-day basis, build and implement the IT components driving the business. A strategy for strengthening meta data capture must start here and should include the following:

• Survey IT domain experts to identify and model available meta data. Look at consolidating tool suites and leveraging vendor supplied tool suite repositories.
• Establish accountability for providing quality meta data as a part of designing, building and implementing systems. This responsibility should rest with the domain experts responsible for implementing a particular component. You will likely find that valuable meta data for a given component is "optional" (e.g., the "comment" field in a table definition). Define minimum standard local meta data requirements and establish accountability for supplying it.
• Identify change control procedures for implementing or changing IT components. The process that changes an IT component should become the triggering event for capturing meta data, otherwise the meta data quickly becomes stale and is not trusted.

Focus "control" type use cases on these local tool or infrastructure suite repositories. This provides value to the domain experts as a reward for supplying higher quality meta data. This solution, however, is rarely sufficient for reaching a broader audience.

Integration Repository

Moving beyond the "control" use case will require linkage and abstraction of meta data across expert domains. This will require the creation of a special purpose repository which might be homegrown or purchased. This repository serves two primary purposes:

• Lightly summarized and aggregated meta data from the tool/infrastructure repositories is stored here to facilitate further analysis.
• The IT taxonomy is established that categorizes, classifies and groups meta data into higher level abstractions. Every technical service provider group in IT (e.g., security, DBA, testing) has a list of the organization's applications. You can bet none of these lists match. Creating the common IT vocabulary is critical for linking meta data across the expert domains. These taxonomies provide the valid values for meta data that must be supplied at the tool/infrastructure level. Furthermore, the low level taxonomies provide the basis for easily relating detail technical meta data to the higher level of abstractions needed to support the "plan" use case.

Create a small central function for designing taxonomies that are applied across IT and to design meta-models at the tool level. However, this central group should not be responsible for filling in missing meta data. Accountability for providing quality meta data must reside at the source, while design of the meta-models should be consolidated to achieve the desired level of integration.

Planning/Strategy Repository

This most difficult aspect of this effort is capturing the business model in a manner that is useful. Loosely modeled concepts on PowerPoint charts are insufficient for this effort, yet most business process modeling tools require too high a level of detail to work. A carefully balanced approach that creates a simple meta-model for defining the business architecture coupled with an interview approach to gathering the data will result in enough usable information to perform planning processes. These business concepts must then be linked to the detailed data and application architecture meta data captured in the "control" repositories. Without the integration meta data described above, this will not be possible.

Information Portal Repository

The information portal repository is not necessarily a separate data store but represents a different look and feel. The data may come directly from various "control" oriented repositories, but requires the integration repository to create organization and structure. Users want customizable views; for example, the user interface would only list data elements associated with certain applications or data subject areas. A higher emphasis is placed on search capabilities and formatting information for viewing online.

21^st century meta data management for IT has morphed into a knowledge and content management project with the goal of capturing, classifying and categorizing all things IT. Pursuing this goal will result in a better informed IT staff and will reduce time to market for new systems. IT-to-business alignment will improve as the IT process and deliverable becomes more transparent to the business and as the business can more readily measure the impact of spending decisions on the IT architecture. Critical to success is recognizing the three distinct meta data management patterns: control, inform and plan. No single vendor provides an overall solution, rather a mix of technologies and in-house developed solutions will be required. Finally, a standardized taxonomy of IT components is critical for enabling an end-to-end solution, where IT technologists and senior business strategists can finally speak the same language.

John Singer is a 24-year veteran information systems professional who has focused on data management activities including database administration, data administration and enterprise architecture in both staff and management roles. Currently working as a data architect at MasterCard International, Singer has experience in the pharmaceutical, healthcare, manufacturing, retail and criminal justice industries. He can be reached at john_singer@mastercard.com.

For more information on related topics, visit the following channels:

• Metadata