I’m amazed at the number of Configuration Management “solutions” that have weak, optional, or sometimes even no automated discovery capability. Anyone who has tried to build out a full Configuration Management Database (CMDB) or undertake any kind of Service Asset & Configuration Management project will know that it is an almost impossible task unless you have a discovery tool.

It’s not entirely clear why so many IT Service Management (Service Desk) tools seem to fall down on the ability to discover and maintain the underlying Configuration data, but I have a personal theory; I think it may come from the evolution over time of ITIL, Service Desks, and the tools that support them.

Back in the day, we had a Helpdesk, whose main function was to deal with end-user question about how to use standard packages, log faults, and arrange for support staff or engineers to visit at their desks. The Helpdesk systems of the time did little more than track the progress of the issue and maintain a record of who had done what and when. There was no need for a detailed knowledge of the infrastructure supporting the user as they were simple, standard, and reasonably static.

Over time the structure and sophistication of the Helpdesk increased, taking on more and more responsibility and additional processes until eventually we arrived with the much more wide ranging responsibilities associated with today’s full Service Desk teams.

But have the tools that the Service Desk works with kept up with the pace of change?

In some ways, Yes they have; certainly the process automation within the packages has come on leaps and bounds, and the provision of ITIL conformant workflows can only be a good thing.

What about the Asset & Configuration Management modules that underpin everything else though?

Some of the enterprise quality (expensive) products have put the work in to provide not only good Configuration Management modules but also the all important discovery capabilities. If you’re lucky enough to be using one of these, you’ll probably be sitting pretty (at least reasonably so).

But lots of Service Desk solutions have not really addressed automated discovery with any real success. In a way you have to feel for these guys; the remainder of the evolution of their products from Helpdesk to Service Desk involves changes and additions that are within their traditional comfort zone. It’s one thing to update and enhance a process workflow engine that you’re already familiar with, but quite another to get into the complex world of discovery agents and adapters.

But, as the consumer of these tools, we shouldn’t have to care about this; we need accurate, reliable and current information about Configuration Items (CIs) that can be used to drive our processes and make informed decisions. A manual (and thus almost certainly out-of-date) CMDB is arguably worse than no CMDB at all, since it can lead to decisions based on false confidence of the details of the underlying infrastructure. You never know what you don’t know until it has caused you pain!

 So what’s the answer?

One approach is to go for one of those expensive Enterprise Service Desk tools that has everything built it, but even if we accept that they have done a good job of building their discovery engine, you already have a system that works well for Incident, Problem etc so do you really want the hassle of moving to a new platform?

Another might be to badger your current provider in the hope that they will up their game and give you and all singing all dancing discovery tool. This might work (eventually) but it isn’t something they can do over night, and there will no doubt be a chunk of extra investment needed to purchase and implement their new module.

The third option (and in my view the preferable / most practicable) is to select a best-of-breed discovery tool and make sure that its database can be federated to your Service Desk solution. By taking this approach you can get a proven solution that is designed from the ground up to do discovery and do it well, which can intuitively identify and understand the inter-dependencies between CIs, and is not restricted in its use to only those processes delivered by the Service Desk. All of this discovered information can be used to support the processes based around your Service Knowledge Management System (SKMS).

Obviously there are a range of tools that you can use, and there will be some cost and effort to deploy them, but you might be surprised at how strong the business case is for doing so. I’m always happy to share our experiences of deploying and using discovery capabilities, so feel free to give me a call at Orb Data on +44 (0)1628 550450 or email me at steve.lawrence@orb-data.com.

Visits: 14