Rethinking the CMS

I first started this post in response to the IT Skeptic’s CMDB is crazy talk post about 2 weeks ago. My own position derives from several observations in the real world:

  1. Few organizations are willing to perform a full spectrum CMDB implementation, due to cost constraints. (In my opinion few organizations actually require this.)
  2. Observation #1 even includes those organizations that have purchased a commercial CMDB software package. They purchased the software to achieve a more specific objective.
  3. And yet most organizations perform some level of configuration management, even if that is as simple as tracking software licenses on a spreadsheet.
  4. Most organizations would benefit from doing a little more than they are currently doing. The “what” depends on the organization.

The ITSM community needs to stop thinking about the CMS / CMDB as a process (which has defined inputs and outputs) or a thing or a database. Instead we can think about it as a broad collection of activities that help maintain information and documentation on the configuration of assets and software inside an organization. This isn’t a black or white implementation where you do it all or you don’t do any–most organizations span the spectrum of gray.

The trouble with ITIL (as if there were only one) is the concept of a CMS is so abstract that most people cannot understand  it. This is by design–it saves the authors the trouble of actually doing anything. I still have trouble describing ITIL’s take on the CMS, and I have done practical implementations in a dozen organizations.

Let’s help practitioners by enumerating and describing the various CM activities that take may take place that are common in the real world. We will explain the benefits and costs associated with each.

For example:

  • Automated discovery of hardware assets
  • Automated discovery of installed software assets
  • Automated discovery of network assets
  • Automated linking of software and hardware assets
  • Automated linking of hardware and network assets
  • Automatic reporting on software compliance and unused licenses
  • Linking Incidents to CI’s
  • Linking Changes to CI’s
  • Linking Problems to CI’s
  • Linking CI’s to end-users
  • Linking CI’s to end-user organizations

This list is VERY incomplete, and there is no out of the box solution for any of the above. There is a wide variety of expression of CI names, CI types, attributes, and statuses of the above items. Each can be automated to different levels.

By making a checklist we can help practitioners and organizations understand what they can do, what other organizations do, and what they should consider in the future. It would be a list of available options, rather than a document of the One True Way dictated high from above. We can expand on Skep’s checklist concept.

A checklist of practical activities could also feed into a maturity assessment.

We can call it the Management of the Configuration of the Configuration Management Database Database. Or we can call it WikiCMDB for short. Stay tuned here for more details.

I am thinking out loud, so everything in this post may be wrong. I welcome your feedback.