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.
