« Theory of Speed | Main | Performance Recap »

December 1, 2006

The CMDB as a Knowledge Base

An executive overview.

In the front-office world of a business, the holy grail of a "360-degree view of the customer" is already old hat.

Well, much of what is now happening in the middle office -- the IT world -- revolves around the criticality of utilizing a "configuration management database", or "CMDB". This database is the key to a 360-degree view of any IT asset. In particular, it is a centralized repository of information about how items are defined and situated as components of the information technology infrastructure on which the business runs.

As a singularly authoritative (or "master") source of information about the infrastructure's components, the database content is very involved in the documentation and decision support for almost any business process workflow requiring IT enablement. But what is it about the components that the CMDB describes?

Typically the components for which the CMDB holds descriptions are referred to as "configurations". A quick survey of the CMDB literature shows that would-be CMDB users can get mired in great controversy about what consitutes a configuration, because there are so many ways to segment a chunk of infrastructure IT and legitimately call it a component. After all, the notion of a component necessarily refers to the idea of some larger entity that the component helps to make up. The problem is that any entity's distinctive identity must be defined with a boundary around its scale, complexity and purpose -- but just as any category may be said to be a subcategory of something else, any entity may be a component of some other entity. Thus it may be unclear where to draw a boundary, create an object, and call it a "configuration". The question always begged is "of what entity is this item a component?"

This makes it very difficult to decide what to include and exclude -- the CMDB's catalog of entities should be neither too general nor meaninglessly specific. How many levels of categorization and subcategorization (so to speak) must the CMDB contain?

In the below, we skip all of that confusion by looking at "things" in a more objective way. First, we take the notion of configuration not as a noun but instead mainly as a verb that has a result. The focus is on the motive for action. That is, nothing in the IT infrastructure is there except through the labor of making it fit into the company of other things -- and our first emphasis is on the labor that takes place to respond to the perceived need for including something that wasn't there before. This allows us to think of a "configuration" as the output of a system of functions, and the CMDB first of all collects facts about that output (and other ones, similar or related, in the same infrastructure ) -- as accounted for by its system.

But why collect the information? The primary reason is to put management of these outputs on a foundation of knowledge instead of on hunch. The CMDB's content can fuel knowledge by organizing its information into the three main contexts that matter to the difference between being managed and unmanaged.

Managed conditions always compare the actual against the planned and the authorized. This indicates three forms of knowledge that the CMDB would support: respectively, models, analyses and histories.

The essential CMDB content will be descriptions of states generated by the functions (as illustrated above), to be evaluated in these three contexts.

However, management tends to root itself in the posture of "operations" -- with the difference being that operations are mainly about organizational responsibilities while functions are about activity. This distinction is more profoundly yet simply identified in the hierarchy of management as shown in the next table. Top-down, starting from a focus on business value, the table rows address the questions "Why are we doing something?"; "how are we going to do it?"; and, "what are we going to do it with?":..

It is easy, then, to recognize the same top-down pattern in management's attempt to associate the needs of the business with the infrastructure that would address it.

Arguably, tactics are derived from respect for the customer's agenda, and functions leverage the offerings of suppliers -- so the primary challenge for differentiated management is in the operational dimension. Not surprisingly, Operations lays out responsibility areas in a way that tends to generally reflect functions. For example, the operational chain of development/implementation/administration/support is, on the surface, an echo of the functional flow of build/release/monitor/maintain. But Operations must intentionally, not coincidentally, associate its responsibility areas with the functions it can govern, if the dynamic is to be called "management". Operations must decide what functions will "execute the infrastructure" and how.

Consequently, what management wants from the CMDB is content that helps construct the artifacts of management that should populate the following framework. In this framework, captured knowledge explains how Operations currently puts functions into the context of the bigger management picture -- the one that generates business value. That overall knowledge-based governance looks to the CMDB to fortify its perspective and acuity on what to change, when and why.

Posted by Malcolm Ryder at December 1, 2006 11:14 PM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/296

Comments

Post a comment