Auto-discovery is only a minor consideration for CMDB

The vendors like to tout auto-discovery as a feature that solves the problem of discovery - how to populate a Configuration database and keep it populated. It isn't. [Oh alright, I'll call it a CMDB so long as we all understand I don't mean the ITIL-defined dream model].

Having given Siki Gunta at Managed Objects a bit of a roasting over her blog, it is only fair to say I agree with her on [parts of] another posting.

MO's BSM blog said:

Beginning a CMDB ... with discovery is akin to drinking water from a fire hose: the data discovered is vast, often duplicative and difficult to filter, and moreover does not really identify meaningful relationships... If not discovery, then where should the project start? ...in existing IT management tools... Discovery or application mapping tools are most valuable when they are used to complete the picture – to understand what has changed in the relationship structure, the configuration of each element, or if new elements have been introduced

I do wonder if Siki is familiar with the concept of change management because she speaks as if using auto-discovery to detect "what has changed" or "if new elements have been introduced" is business-as-usual, whereas of course it isn't. We should know about them via RFCs. Auto-dioscovery is used as an audit tool for exception reporting to detect subversion of change control. That isn't at all clear from a number of postings on the BS...M blog.

And I prefer to use the term "auto-discovery" to differentiate from the discovery process, which is a human process not an automated harvesting, though assisted by it.

I don't necessarily agree that existing tools are the best source of initial data: often [usually?] the data in them is crap. Many times auto-discovery along with pains-taking manual discovery is required to get decent initial data.

But I do agree [finally getting to the something nice to say]

"a conventional wisdom that says that building a CMDB is a linear process – with a beginning and an end – but as the saying goes, it’s the journey that’s most important"

The way ITIL defines CMDB you are unlikely to ever get there, and I believe you will never get there with a good return on the investment required nor with that being the best way you could have used the money. So I like the idea that CMDB is all about the journey not the destination, thank-you Siki. I haven't spoken to Ivor Macfarlane in a while [he may never speak to me again :-D] but second hand reports tell me this idea is what they had in mind with ITIL V3's SKMS: that it defines the end-game or idealised model, not an absolute requirement for everyone.

Now if we can just get that message to all the companies blowing their money chasing these ideals.

The other idea of Siki's that I agree with is that auto-discovery is not such a big deal. It is not central to any CMDB, and using it to regularly and automatically populate a CMDB is a direct violation of the principles of Configuration and Change Managements.

Vendors like to talk up auto-discovery because it is sexy, it is technology (i.e. they can sell it), and it looks like a silver-bullet solution to one of the most intractible problems of CMDB: discovery. Of course it isn't but that doesn't stop them painting it that way.

Of course Managed Objects (and other vendors) are busy painting federation/integration technologies the same way. But that is another post...