Configuration Management

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.

2 replies on “Rethinking the CMS”

Although I never said it as elegantly as you, Ian, I said similar things to my customers. In particular, as we discussed the theoretical description and benefits of the CMDB, it is important note the CMDB is a big elephant to eat, and the way to start is one bite at a time.

Eating the low hanging fruit is perhaps a less gruesome analogy–those capabilities that satisfy the most immediate pain points or requirements. The initial engagement usually meant identifying data sources and pain points and filling in the gaps to achieve something useful.

Not everything that is theoretically possible should be done.

By the way, I promise I will finally pick up a copy of the USMBOK in January 2011 (esp. with the sale).

As you say – ITIL is a sharp object you give to a 3 year old in a busy household. It needs bumper bars everywhere. I work with IT organizations that have failed or are failing in their ITSM efforts. They have failed the customer in every way – and in part because they read ITIL as something they had to do to ‘succeed’.

Success is not implementing or improving IT processes and practices – thats the what and the how part of the whole endeavor. Its ensuring that you know your customer’s, their needs and wants, their outcomes, and the service experience they will endure to get what they want done, done.

ITSM is the effort of building a holistic systematic method for designing, operating, managing and continuously improving the service experience. It has become polluted somehow from this aim.

A CMS and the infamous CMDB is a logical representation of anything you might need to pursue the ITSM objective – read manage the service experience. It starts with the customer and ends there. It does not imply a single repository as the CMDB did – a CMS as defined by ITIL admits the information is all ‘out there’ it just needs aggregating and indexing to support the ITSM agenda…. Effectively a smart Google or Bing for IT.

So, IMHO – leave your IT body for a moment and assume the personality of a customer and work your way back in when defining the CIs you might need to put your hands on and manage…. gotta run…

Comments are closed.