Get it straight: CMDB can not be auto-discovered

This line in a Butler Group white paper synopsis pressed a button for me:"Service Configuration Management enables quick establishment of Configuration Management Database (CMDB) through auto discovery". I respect the Butler Group more than most analysts, and I am too tight to buy the full text from them, so I hope the synopsis is a bit misleading. Though from the tone of the rest I fear it isn't. This pernicious idea turns up regularly, mostly from software vendors. It must be stamped out. Read my lips: CMDB CANNOT BE AUTO-DISCOVERED.

Tools auto-discover almost all the physical assets in the environment, and plot their network inter-relationships. From the same page:"Configuration management involves the identification and definition of the assets within the IT infrastructure such as switches, software, and servers, and the relationship between the various components". No it doesn't. That is only the bottom layer of a CMDB.

Most tools cannot auto-discover the software layer and the inter-relationships of software components across nodes. Web Services is making this almost impossible because it is so loosely coupled.

No tools can auto-discover the logical functions. And no tools can automatically relate those functions to processes. And no tools can automatically relate those processes to ITIL services. And no tools can automatically relate those services to business units and stakeholders. And no tools can autodiscover and relate SLAs or UCs or....

It is all manual, dammit. And that is why it can't, practically, be done.

When will people stop muddling asset databases and CMDBs? Vendors play this game all the time. They offer an asset database, call it a CMDB, and promise the benefits of a CMDB: how does discovering my network diagram help me understand what business service is impacted? Unmitigated bullshit. I expect better from Butler Group.


Does Tideway deliver on it's claims?

I recently viewed an EMA webinar on CMDB co-hosted by a vendor, Tideway Systems. Tideway doesn't market a CMDB itself, but has a product that integrates with one's CMDB - their claim is that their product auto-discovers more than assets and their physical relationships to each other. Granted these sessions are mostly the vendor looking to drum up business, but this one intrigued me and I may actually go so far as to contact them for a closer look. Here's the url to the page on their site with the product claims:

If you haven't seen it and have any interest, link to the rebroadcast of the webinar is but note that you'll need to register unless your organization is an EMA subscriber.

I definitely agree the previous comments in this thread that the vendors whose solutions I've come across in CMDB implementations totally over-hype their product capabilities but that a good auto-discovery tool (once you get through the deployment headaches) saves a good deal of manual effort in populating CI attributes and physical relationships.

Thanks for drawing that to my attention

Thanks for drawing that to my attention. I've addressed this kind of technology already elsewhere, but I feel a new blog entry coming on.

Oh, and Abigail: if you turn out to be a Tideway (or HP) stooge then may your cat throw up on your bedspread.

No, just another fool implementing Change & Config...

I actually implemented Change...and then got stuck with Release (under HP's 'best practices' they draw a hard line between 'build & test' and 'release to production' and my former company decided to make 'build & test' out of scope and only do 'release to production'...) and was also part of the CMDB initial then on-going design, roadmapping, etc. I decided to take this a position in a smaller, not-publically-traded firm this past summer for, among other reasons, the opportunity to do it better, more service-management-centric, and with the freedom of NOT having management freaked out about SOX compliance and making things worse than they were before. So far, so good - looking at various products, reasonable funding is being made available for the toolset and I should have Change migrated from pretty much paper-based into the tool, and a rudimentary CMDB deployed by this coming summer at the latest. And then of course I start thinking about moving it further along and whether it's really possible to get to a true CMDB (which I haven't heard of anyone REALLY having done). So I am trying to learn from others that have already explored some of these type of products and who, like myself, have some implementation experience that has taught them ITIL isn't an altar at which to genuflect, but, simply a framework that you can choose to apply components of if it's going to improve things for your firm/company.

Please tell me about anything you've come across that may hold promise for getting towards that closed-loop nirvana.

The thing I have come across

The thing I have come across is a verity not a tool: tools don't work. Not for what people ask them to do, which is fix a problem. Put your tools in, maybe even design a process around them, but it will fail. it might take 12 or 24 months to fail but it will fail.

Start with the people, change the culture/mindset/habits/attitude, then help those people look at process. Once process requirements IN THAT ORGANISATION are understood, find a tool to fit. Any other sequence is imposing a change on a culture that has not accepted it and is therefore doomed. SO in my usuall exaggerating fashion, I'd say "tools don't matter"


Vendors will stop muddling asset management databases and CMDBs when they can no longer get away with it. They are able to get away with it at the moment as the vast majority of people out there cannot tell the difference between them... because they themselves do not know. Configuration Management is probably the least understood of all the ITIL "processes". As it is also stated as being the second process to develop, after Change Management, in an ITIL implementation, it seems to me that without the right guidance, and a practical approach, organisations that embark on any Service Management uplift using ITIL "by the book" will be setting themselves up for failure. I have seen plenty of successes using the ITIL framework and, notably, none of them have implemented a CMDB, as described by ITIL.

By the way skeptic, this is my first time to your site and I've enjoyed reading your points of view.

You're welcome

As I have enjoyed reading yours. thanks.

CMDB & Autodiscovery

Good day all,

I will have to take Antonio's position on this. Skeptic, you're right, in that autodiscovery is not enough but the reality is that for organizations that have done no real "proactive" configuration management, this "reactive" step helps them identify and document the mess they've created.

I teach my employees and my customers that there are two types of Configuration Management: 1) Reactive Configuration Management and 2) Proactive Configuration Management. I've described the two, below. But first, lets take a quick look at what Configuration Management really means.

Configuration Management is the process by which we manage our Configurations. This means we proactively manage our:

  • Design Configurations
  • Build/Implementation Configurations
  • Deployment/Distribution Configurations
  • Installation Configurations
  • Instantion Configurations
  • Execution/Behavioral Configurations
  • Deconstruction Configurations
  • Rollback Configurations

In all of this, there are two types of CIs that matter, those that are used to build and are only seen by the builders and those that we deploy (which can include some of those that are used to build) and are only seen by the people that have access to the targeted distribution environment(s). I believe ITIL incompletely refers to the latter as Release Units (RUs). NOTE: I am disappointed with how ITIL distinguishes between CIs and RUs since they have left many flaws and gaps in the RU definition and don't seem to acknowledge that many CIs, themselves, can be RUs. Example: A script that does not get compiled but that does need to be deployed and run by an interpreter.

Anyhow, Configuration Management is the process by which we manage anything and everything that is important, in the list above. Here is something that IT people forget: CM is important to more than just IT people. For example, facilities people need to manage the Configuration of their facilities. Leaders have to manage their organizational Configurations, and so on. Therefore, CM is not just important to IT people and a CMDB that only caters to IT is incomplete. To go one step further... a CMDB that caters only to IT infrastructure resources, as implied by ITIL, is even more incomplete!

So now that we've highlighted what Configuration Management is, let's talk about two scenarios. The first is an organization that never does CM and has a mess in their environment that they're trying to inventory and document. This is where autodiscovery comes in. In this case, Autodiscovery is for the enterprise that has run by the seat of its pants for many years and now has to be accountable for its mess. They use it to scan their infrastructure for what they own, hoping that it will give them some insight into the mess they've created. The second example is an organization that proactively documents and manages their configurations, both before and after they've deployed. In this case, Autodiscovery is used as a way to ensure "stability and synchronization" in their deployment infrastructure and environments. They use it as a means to ensure that no one has changed something that hasn't already been planned, as they use Autodiscovery as a means to check the "actual" against the "expected". It is from these two scenarios that we have two new definitions of Configuration Management:

Reactive Configuration Management: The practice of attempting to understand an enterprise's Configurations after they have been created with no formal Configuration Management controls in place.

Proactive Configuration Management: The practice of proactively managing an enterprise's Configurations through their entire lifecycle, starting from planning and all the way through to their eventual decommission.

My views on the above are simple, if you're not performing proactive CM then you're not managing your enterprise. It's managing you.

A touch of autodiscovery in the proactive CM scenario is a good thing, as it helps keep things in synch. Autodiscovery in the reactive CM scenario is a bad thing, as it means enterprises are using autodiscovery as a means to tell them what they should already know. It means they didn't do their job...

Anyhow, I hope this helps.

Have a great day!


Frank Guerino
CEO & Founder
ITIL On-Demand

It doesnt do all the work, but helps

Well, skeptic.
As usual, I agree, but not 100%. Obviously, it asset discovery tools can not create a full CMDB, nor they can't create a good asset database, because tehy can not discover logical things like, for example, location, owner nor warranty details.

But they help. They help doing an initial discovery when you are initially deploying the process and they help filling tons of data when the CI is inserted into the databse.

I don't like those things creating the CI, because the discover, for example, my PC when i'm working in a customer's network, and MY PC IS NOT THEIR

But what I love is to allow those things discover and fullfill the forms with all those technicall fields needed for support.

No tool will discover 100% of the assets, and no asset will be 100% discovered, but tools are a good aid.

Ops! And I forgot something: remember that the CI has to be created BEFORE it has been installed, so the first creation of the CI has to be done when it is bought, or when it arrives to warehouse.

Antonio Valle

"The safe course leads ever downward into stagnation." -- Frank Herbert

Syndicate content