most sites don't

skeptic — Sat, 13 Sep 2008 09:34:25 +0000

Hi dave

I'm impressed by your approach of selling something clear and useful instead of a colourful bandwagon. And I think we are in agreement. To summarise your position in a few of my words: you need a CMDB (or somethign like it) if your site is sufficiently complex or advanced.

Which is the exact flipside of my position: most sites don't.

Who and how does a CMDB actually help?

cotswolddave — Sat, 13 Sep 2008 09:08:09 +0000

Hi skep,

Having viewed the CMDB chatter for a few years, it still seems that the CMDB concept is one of the best drivers for vendor marketing campaigns of any form of repository of information about the technical or services infrastructure. I'm a vendor myself and I've dropped the term CMDB from most of our literature and the product name as I found myself explaining what a CMDB could be, might be, should be. So we don't cmdbs now - we do service mapping tools! Even more ironic, we link our service mapping tools to CMDBs! This could be called a federated CMDB - but that would be even more confusing so we provide "integration".

As a long term skeptic, but someone who has to make a living from delivering software and services in this space (mainly through passion) I thought a few words on justifying a CMDB approach from my own experience might be helpful. The problem is I that I have to define what I mean by a CMDB first. In my case I'll choose the mapping of services to components, as the asset side does'nt tend to do much for service management processes like change, incident and problems.

You don't need a CMDB for change/incident/problem management, but it does help. Without a CMDB I find the following happens;

a. Technical teams can't easily understand the potential risks of a change, it relies on personal energy and experience
b. Its difficult to identify the service owners for communication and involvement
c. Change submissions have many errors or omissions which require additional filtering / interpretation
d. New information comes to light during discussion of changes, which results in re-submissions or unnecessary risk
e. Incidents are initially allocated ok, but never closed off against defined CIs, so service reporting can't be automated and problem analysis becomes protracted
f. The usual confusion over naming because without a CMDB, it often difficult to ensure consistency of terms
g. Dashboard, monitoring tools etc. all use different interpretations of whats makes up a service so there is additional mis-communication.
h. Risk disciplines - security, business continuity, capacity have to duplicate data to try and get a "business" view for their own needs.
i. And the big issue - It takes a long time to get a change through the system, not the change form, but the whole project - request, requirements, planning, change, scheduling, reporting etc.

Many of the above aren't an issue for smaller organisations because there is less people issues and fewer silos. With additional skills (training, product knowledge etc) and good motivation then the need for a CMDB is less. In bigger organisations then there are probably outsourcers involved, teams are spread across multiple locations and so on, communication becomes more difficult and the systemic problems above start occurring. The ROI can't be identified because communication is the problem and that's a strategic issue. So without a CMDB, people have to work harder at communicating - not always a strong point of IT.

If management teams want to change the working practices and get better controls in place, they will have to bite the bullet and look to a CMDB as a foundation for improved communication across teams. But it does depend on what you mean by a CMDB....

Dave

The IT Skeptic - Comments for "What do all the sites without a CMDB do?"

most sites don't

Who and how does a CMDB actually help?