The Role of Configuration Management Systems within the Knowledgebase

If you have been sucked into the world of Twitter, like I, have then you have seen all the buzz that has been going on about "Configuration Management Systems". To sum it up, basically there are 3 camps with opinions on the concept:

Camp 1) Says CMSs don't exist and are fantastical.

Camp 2) Says they are fundamental to your IT Service Management strategy and it is impossible to live without them.

Then there is where I personally sit...

Camp 3) CMSs exist in every organization. Organizations that say they don't have one wouldn't know one if they saw it. Organizations that say they don't need one are already using it.

So for the newbies in my blog world, let's cover what a CMS is.

Simply put a CMS is a logical collection of information about business IT resources. Over the years they have matured, but pieces of the CMS are asset databases, system maps, network diagrams, software architecture diagrams, IP address lists, escalation procedures, etc...

As you can imagine, it is not easy to document the multi-dimensional relationships between hardware, software, locations, people, versions, ahh... my head is hurting.

And there you have it, the reason why there are so many people in either camp 1 or Camp2: People try to take in too much information and map it.

This is also the biggest reason CMDB implementations fail. (CMDB is a set of databases that hold specific configuration data. CMDB's link together to make the CMS.)

Be that as it may, unless your IT shop is super small or completely defunct, you most likely have quite a bit of information about your systems documented. The challenge, then, is how to find the info and make it usable.

Everyone wants a robust knowledgebase. They want this knowledgebase to tell them everything they need to know. How do we fix problems? Where is the equipment is located? Which systems support which users?

All of this is valuable information that is critical to supporting the business. However, like the system data, you may have it, but it is probably difficult to find and tough data to manage.

This is where a CMS comes in. A CMS simply is a utility to help relate documentation together for ease of use and finding. Many organizations turn their Wiki's or Intranets into a CMS. Of course you can leverage other powerful tools such as Visualization tools, discovery, monitoring integration to help give more context to data. Like any data source, it is important to remember Garbage In-Garbage Out. So it is critical to make sure you have a source control/change control on the content that is in your CMS.

When this information is brought together through one source, the Service Desk and others can utilize it to find the information to solve problems, to resolve outages, to analyze risk, etc...

Now that we have a clear picture of which systems depend on which, and what services they provide, can't we leverage this for better rules related to monitoring for pinpointing root-cause?

We sure can. Next month I'll take us down a path of leveraging the CMS relationships for automating dependency modeling within end-to-end monitoring tools.