The hero culture runs deep in most IT departments.   In many places where I have worked, the staff who get the most kudos are the ones who need to pull the all-nighter to make things work, or have to be involved in everything for it to be successful.

while there is always room for people who go above and beyond the minimum to get things done, ultimately the hero mentality is a big reason why so many IT departments are stuck in a reactive mode, constantly fighting fires then slapping each other on the back for a job well done.

The real hero is the employee who through proper planning doesn't need to do the all nighter.   Another hero is the employee who documents his/her work and makes it available to everyone (e.g. via a wiki) so they don't need to be available for anything in their area to function.  

Instead of rewarding the hero, IT management need to examine why it was required in the first place.   Were processes followed?  (sloppy change management is a big culprit here).   Is adequate documentation available on the key IT systems?   Was the right level of planning done?  Were estimates correct?   Was the outcome as expected.

The real hero can answer yes to all of these questions.   The so called hero answers no, but gets rewarded because it worked out in the end.  

Who are your real heroes?

While many IT organizations embark on CMDB projects.   Few succeed.   Why?   The obvious answer is that their CMDB turns into a junkyard and cannot deliver any meaningful value.

Why does this happen?

The first part is that a lot of CMDB projects start out without a clearly defined problem that they are trying to solve.   Instead, they focus more on the supposition that ITIL says a CMDB is needed, and the vendors say a CMDB is needed, so a CMDB we shall have!  Or alternatively, they try to be the silver bullet for all the ills in the IT organization.   These projects are doomed from the start.

The second is that they often over complicate the CMDB.   Instead of populating it with just enough data to solve that original problem, it becomes a dumping ground for every piece of information that they can possibly dig up - e.g. doing SNMP sweeps of the network and dumping port or NIC card information in the CMDB..   Are you going to create a change request on one NIC card?  No.. you would do it on the server, so why have it in the CMDB?

A third problem is how the CMDB is populated and updated.   A totally manual approach is also a sure route to fail except in the smallest shops because nobody can keep it up to date, and even if there is a process, during busy times people will ignore it.   Dependency mapping technologies are also not the complete answer as they are not 100% accurate and can over populate the CMDB with junk too?   So what is the answer?   Probably somewhere in the middle.    At least identifying the key infrastructure components and the software that runs on them is a good start.   Your existing monitoring tools can probably tell you this to start with.   Maybe a network scan can also identify infrastructure that is not being monitored too.   But this information should be reviewed before its just dumped into the CMDB.

In summary then, if you don't want a junkyard in your company, consider the following:

1. Do you really need a CMDB?   What is the problem that you're trying to solve?  Is there another way?     Don't listen to the CMDB vendors here.    To a man with a hammer CMDB, every problem looks like a nail sales opportunity.   
2. Clearly define the problem and make sure that its agreed and the expectations are set. 
3. What is the minimum set of data that I can populate the CMDB to solve the problem that was defined in #2
4. How can I automate the data in my CMDB in an accurate way?   Even minor inaccuracy in the CMDB makes it a junkyard
5. How can I measure the benefits and costs of the CMDB to make it worthwhile?

If the CMDB can claim one thing its that its been in the 'news' a lot - Nothing gets a group of ITSM consultants/practitioners going than talk about the CMDB, its value, different approaches and so on. But does the hype translate into reality, or is the CMDB just another one of a series of IT fads that explode onto the scene, but are forgotten only a few years later?  

Even with the more pragmatic approach in ITIL v3, the CMDB continues to be over hyped. Despite all its attention, I saw a statistic at the recent Gartner conference that only 5% of the fortune 500 has a fully implemented and working CMDB? 5%! What a poor hype to reality ratio!  

This ties in with my observations too. In the last five years or so, I've only seen one CMDB that was really delivering value for that business, and fully integrated into their ITSM processes. When I heard how much time, effort, resources and money they put into it, I had to go and sit down for a while and have a glass of water, so while it was adding value, the ROI was very questionable. But outside that, I had seen a litany CMDB projects that either end up being only somewhat useful, or fall by the wayside and slowly get abandoned as they are not updated or maintained. Unfortunately, I also saw quite a few projects start simply because 'ITIL says we should'. No wonder these failed. 

But back to the premise of this article - will the current financial crisis give the CMDB hype the cold shower that it deserves? I think so. 

It’s certainly not going to eliminate the CMDB, but I do believe that when IT organizations are asked to cut budget, one of the first candidates is going to be the ongoing CMDB effort. the project probably won't get scrapped yet, but it probably will get put on hold, and then die a slow death starved for resources and attention.  

I also think that new projects are going to have to demonstrate a clear ROI, and without using funny math, its pretty difficult to justify the CMDB. I think the CMDB hype has flourished mostly because of a view that the CMDB was needed for other facets of ITSM, like BSM, Change Management and so on, but I think people are waking up to the fact that to implement a CMDB to solve these problems is like using a tank to kill a cockroach.  

It is going to be interesting to see. Many ITSM vendors (BMC in particular) have aligned their considerable marketing machine around the CMDB concept. Will they be toning down the message over the next few years?

We're already seeing more and more skepticism from the analyst community too, with finally some acknowledgement that the CMDB is not the center of the universe and that its not a necessity for most IT shops.   Of course there are cases where the CMDB does make more sense, such as during major M&A activity, or data center moves, but even there,  other approaches can be considered.

In summary, I think we're going to see the hype die down, with more focus on delivering value for the business and saving costs and less on internally facing systems with questionable value.

One of the most damaging trends i've seen in a long time in ITSM is the propensity of some users to treat ITIL more like a religion than a set of best practices.

In some sense, it's almost like the creators didn't realize the beast they've unleashed.

I've been in discussions at multiple IT organizations where various processes, tools, changes are being made not because they make sense for the organization, but because of a misguided belief that "ITIL Says we should....."

I've seen shouting matches over trivialities such as the meaning of Service Level Management, Help Desk vs Service Desk, Ticket vs Incident and many more.

Overall, despite some of its shortcomings, I like ITIL and would advocate that IT organizations should use it as a valuable reference point, and at least at a conceptual level some guiding principals.   But to take a fundamentalist approach to ITIL implementation simply makes no sense and is somewhat of a cop-out in terms of thinking about what problems the organization might have, and how they can be solved.

Instead of rigidly implementing what the books say, why not take a more general approach to ITSM and think of some of the core principles that good organizations embody, for example:

• Focus on business services, not the infrastructure
• Managing Change
• Measuring and reporting on success/failure
• Separating out getting a service working from the process of fixing root cause
• Understanding the lifecycle of services

From there, organizations can cherry pick the various parts of ITIL, other standards and things that they are already doing well, even if they don't fit the ITIL approach.