Don't fall for the demo: an asset database with bells and whistles is not a CMDB
This article has been podcast
Don't fall for the demo: anyone can set up an asset database with enough relationship bells and whistles on it to fool themselves and others that they have a CMDB. People set up a CMDB and either grossly overspend beyond any reasonable ROI to complete it, or settle for the delusion that an asset database is a CMDB. The vendors of service desks sell an asset database that looks a bit like a CMDB then claim all the benefits of a CMDB.
They both defended auto-discovery as a useful tool for CMDB. We aren't agreeing or disagreeing because we are talking at slightly crossed purposes.
Yes auto-discovery is a useful aid. Frank you sum up nicely the two scenarios where it is useful. I like the concept of Reactive and Proactive ConfigM. I've used the same model for Problem for a while but not thought to apply it to Config. I'm sure I'll remember to attribute it to you :-)
But we all agree that auto-discovery only does some of it. So I have two main points that I think you guys are not addressing:
The REST of the CMDB is the hard bit. Auto-discovery automates the easy bit. If I don't have an auto-discovery tool, I can take any geek and get him/her to map my network for me manually. But I need a higher-value person to work out my logical processes, services, stakeholders and SLAs and interconnect them all and connect them with the easy bit, and I need that person(s) on staff because I need to keep that data current. I just don't think that is do-able within any sensible ROI contstraints, sorry.
So instead most organisations (those that don't grossly overspend to do the whole thing) end up with an asset database with enough relationship bells and whistles on it to fool themselves and others that they have a CMDB.
My second point is that the vendors of service desks pull the same trick. They sell an asset database that looks a bit like a CMDB then claim all the benefits of a CMDB.
Don't fall for the demo: anyone can set up one server linked to one process linked to one service, so the service comes up on impact assessment of a change or outage (I've been there - I was a vendor).
Work out how many of these you will need to set up in your business. Scope the effort required to manually discover and populate the details of all your processes, services, stakeholders and SLAs, and then all the inter-relationships between them. Then figure out how you are going to deal with the bits that don't play nicely:
- itinerant devices (portable and wireless devices)
- load-balanced Citrix or web-server farms
- Web Services and other loosely-coupled dynamic relationships
- All the new on-demand computing where you don't even know what device a process will run on
Then scope maintaining that data current as services come and go, people come and go, the company reorgs and outsources and....
It just doesn't add up, sorry. It is another of these techno-geek fantasies to fix everything that looks good in concept and wildly impractical in practice.