Immediate value of a CMS - yes it's possible

Configuration Management Systems (CMS) = VALUE... not for most people.

In fact most IT shops I've spoken to over the past 6 months have abandoned their CMDB/CMS strategies. Why?  ‘No immediate value’ has been their biggest complaint.  They are not seeing the benefits of having the relationships of assets. 
The clear distinction, between the organizations that are moving forward with their CMDB and CMS strategies and those who have thrown in the towel, has been the ability to effectively tie in their visual operations to their CMS. 
These successful organizations are leveraging the relationship information to show which apps are running on which pieces of the infrastructure and are providing a view of this relationship to their 1st and 2nd tier support teams.  Empowered with this information they are finding their troubleshooting process of elimination faster and more efficient. 
As any of us in the support arena know, the work to get systems back on line consists of 80% finding the problem and 20% fixing it.  So armed with this visual aid to help root out and verify the components that are working, the practitioner is closer to finding the one that is not.

So here is my advice if you are on the verge of blowing up your CMDB: 
First: Verify that you have the right grouping.  If your CMDB is grouped by technology, then it will not help Tier1 and Tier2 teams, who are  getting complaints about applications. 
Second: Create a visual element for the application and show logical relationships to the systems that support it.  Link those elements to your existing CMDB for more current and accurately collected data.   

It's by no means the Nirvana that ITIL V3 pictures for us, but it will at least allow you to leverage the work that you have done, and to start making the data and information you have more meaningful and relevant.

Check out these tools for a quick start and easy deployment: 

OpenSource - OneCMDB or BizDiag

Commercial  - NI2or MS Viso

Of course, BSM tools can be leveraged, but they are not going to be quick and easy to deploy.

Special Note: I am doing a weekly Internet Radio show called "ITSM Weekly" with Chris Dancy (ServiceSphere) and Matt Beran (Service Desk Manager).  Please check it out. Would love to hear your feedback.

ITSM Weekly The Podcast Week 1 from ServiceSphere on Vimeo.

Next BLOG - Is ITIL losing its steam?  Seems like the process framework is losing ground in the US; what does that mean?  What will replace it? 

Special edition - Service Value Presentation by Matt Hooper

OK - so I am not a PRO blogger. You have not seen my blog full of pics and videos. Just countless hours of high-value IT tips blah.. blah... blah.. OK, I get it, I need to pick it up.

Well, it will take me some time to get there. So in the meantime, I have posted a recent presentation I did for a CIO user group in Waltham, MA. sponsored by Inforonics.

YouTube limits the videos to 10 minutes, so I had to post it in 2 parts.
Here is Part 1:


Here is Part 2:


This presentation highlights the aspects of creating and sustaining value. Why we need to view our outcomes as the qualitative measure of our value, and not the time we put in, or the skills we have.

Sorry for the sound being so low and the quality being a bit poor. (Hey, we're in a recession).

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.