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? 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...


Tyranny of Tools

In 2005 a vendor (C _ )was selling my company the so called auto-discovery feature in CMDB - my opposition to the decision was like a whimper in a storm - because the deals makers' ears are too big for small voices.

Today, we laugh at the wasted expenditure - no one uses the database.

The point is: these vendors succeed because they are selling an apparently silver bullet, senior IT managers succeed too because they are getting a silver bullet solution (paying a fortune though) - the organization moves on forgetting the mistakes. Consultants with small voice move out with this insight - which actually helps somebody else, later!

autodiscovery that is inline with config/change management

I've seen an auto-discovery approach that respects config/change management discipline principles.
The tools driven by policies that describe what the configuration should be seem to be better suited for this. These tools can create exceptions to be investigated/approved by relevant people when a configuration change is detected, can roll the change back automatically or after approval by someone, etc.

I think Skeptics differentiation of discovery (business layer discovery) vs auto-discovery (technical infrastructure discovery) is valid and useful, though not sure people would understand it as these words are not that descriptive of the intent.

Unfortunately, even the auto discovery tools for technical infrastructure are always that great. They have just moved to the application layer, discovering the relations and dependencies among application components, and contrary to common belief, most network discovery tools are far from identifying all the necessary dependencies. Monitoring folks have been building these manually for years.

Element vs. enterprise config

Parameter management at the element level is a different animal than dependency discovery. I've gone into detail on this here.

Charles T. Betz


Hmmm, seems to me this is more complicated than what you're letting on.

There are different levels of "discovery." Here the focus is on the top level "uses" relationship. That's the roof. Prospects seem to really like the visualization tools. They are convinced that Change and Config Management will suddenly become a breeze when they can "visualize." Never mind the actual work - the vendor told them it wasn't necessary.

There's still the parent-child, connected and installed relationships. Of course those relate very well to the Asset Management lifecycle. That's the foundation and the walls.

I'm always amused that organizations believe they can put the "roof" on Config Mgmt without building the foundation and walls first.

Cary King
Minerva Enterprises
Managing Partner

useless so-what trivial technical detail

See my comment above. All the useless so-what trivial technical detail that matters to one geek in a cubicle is a doddle to autodiscover. The "is connected to" or "is installed on" can be automated.

The "uses" mapping from a conceptual service can't. Nor can "owns", or "supplies" or "provides warranty services for". That stuff is hard and manual and complex and volatile. And it is the stuff that everyone needs in order to answer the important questions. If I change this will it impact an SLA? Does it matter if this is broken?


I work with schools on an ITIL framework called FITS (see
Network Managers love autodiscovery. Why - because it looks like you are doing something and have control where that is not the case.

I run a very small organisation and we've spent 5 years trying to build a CMDB. Many dead-ends followed. Many technologies explored and rejected. In the end we decided the least effort and lowest cost method to do this is to have lots of documents. Not really a database. Not relational. But it does sometimes have some use. We can verify the data in them. We do update them when we make authorised changes.

If anyone knows a better way please let me know.


a CMDB named Sue

I'm a big fan of FITS and have promoted it, including on this blog.

When you say a paper CMDB I think that is the same thing as a "CMDB called Bob" or Sue, i.e. the most cost efficient and genuinely effective CMDB is still embedded in wetware: in someone's head. Best if there are two of them in case the proverbial bus comes along, but no technology comes close to matching Sue for genuine relational analysis and implication deduction.

A CMDB named skeptic is a silo

Trouble with that is in a big company, Bob and Sue can't possibly keep up with everything that's going on. In fact they represent .001 of the staff. So, ya kind of need technology, helps humans deal with what's not humanly possible. And we've got all these silos of data already so it sort of makes sense to piece everything together. The problem is that everyone in IT thinks in their own little world. Even a skeptic thinks in a silo -- I guess its hard to think big when you live in a shack in country that makes the Outback seem as crowded as London.

It is the high level stuff that needs wetware

Technology is good for managing those silos. Discovering the network, inventorying PCs and servers, managing software lifecycles, deploying packages...

It is the high level stuff that needs wetware: reconciliation, service mapping, impact analysis, contractuals...

From the new IT Skeptic book:

The Byzantine complexity of the modern IT environment means that the only device capable of grasping the implications of a change or failure in one component is wetware. Vendors claim that software tools exist with this miraculous ability but only a human can understand whether it matters that one server is out in a load-balanced farm of web servers supporting UDDI lookup to Web Services providing functionality common across four applications. Make sure more than one person can do this, and keep them happy.

Even if you implement the most advanced artificial intelligence available to deduce the conceptual structures in the data, sooner or later it is going to do something really dumb. Just once. And from then on everyone will go ask the wetware expert anyway, to double-check what it says.

Syndicate content