The IT Skeptic - Comments for "Auto-discovery is only a minor consideration for CMDB "

Tyranny of Tools

Ravi Putcha — Fri, 04 Jul 2008 05:14:56 +0000

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!

Element vs. enterprise config

Charles T. Betz — Thu, 03 Jul 2008 13:54:04 +0000

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

Charles T. Betz
http://www.erp4it.com

autodiscovery that is inline with config/change management

Berkay — Thu, 03 Jul 2008 11:52:04 +0000

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.

useless so-what trivial technical detail

skeptic — Thu, 03 Jul 2008 09:03:09 +0000

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?

It is the high level stuff that needs wetware

skeptic — Thu, 03 Jul 2008 08:56:39 +0000

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.

Discovery

Cary King — Thu, 03 Jul 2008 04:41:28 +0000

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
www.MinervaE.com

A CMDB named skeptic is a silo

Visitor — Thu, 03 Jul 2008 04:32:45 +0000

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.

a CMDB named Sue

skeptic — Wed, 02 Jul 2008 22:16:09 +0000

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.

Hallelujah

Alex Jones — Wed, 02 Jul 2008 14:05:00 +0000

I work with schools on an ITIL framework called FITS (see http://becta.org.uk/fits/index.cfm)
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.

Alex