Another problem with autodiscovery

Was discussing autodiscovery with someone the other day who pointed out that regardless of the accuracy of an autodiscovery tool, the question it can never answer is whether the discovered assets are needed.

We've all heard the stories about the mainframe-era reporting office dutifully printing out reams of greenbar reports and shipping them off to workgoups where they were promptly discarded, or even greeted with bewilderment. How many of your servers are in the same situation: running applications, services, batch jobs that are no longer actively in use?

Autodiscovery will be an important element in the IT supply chain, but it needs to be backed up with process and sometimes a lot of shoe leather (or its virtual equivalent).

Thoughts?

ctb

Comments

[Chris York]

I agree! There needs to be someone evaluating the items discovered and making a human decision on whether this is useful or not. If your autodiscovery tool is feeding your CMDB (or is acting as a CMDB directly), then the concepts of owners could possibly deal with this issue. If every CI has an owner, and there is a process whereby all owners have to make a determination that if all CI's they own are evaluated and classified to determine if they are used/needed/wanted, etc. This would then validate the discovered items. The only question then is what to do with newly discovered items. Who owns those?

[Chuck Bies]

We are working with the Business Continuity Planning team to identify the critical applications and their underlying infrastructure components. We are looking at investing in an application auto-discovery tool to validate the application <-> infrastructure mapping and then monitor for changes. I think that by teaming up with either BCP or DR, you get a very good perspective of what applications and infrastructure components are critical. As new items are discovered, we plan on working with the BCP / DR team to determine their criticality, and address how they were introduced into the environment without going through Release Management. On the front end of the application lifecycle, we are planning on working with the application portfolio management team to classify application criticality, and register the application in the CMDB through the Release Management process. This would include running the auto-discovery tool to capture the application <-> infrastructure relationship map.

[Angus McDonald]

More recent autodiscovery tools like Snow Inventory are being linked with usage tracking tools like Snow Metering to give administrators a picture of not just what software is installed on which machines, but whether it is being used, by which users and for how long.

This can help identify situations like:

* One user asking for a specific application to be installed on many machines as they move desks or borrow other people's PCs.

* Software being used inappropriately, e.g. the full version of Photoshop or Acrobat being used to view PSD/PDF files, when a free/cheap viewer could be used.

* A user running software from a fileshare or USB key, that is not actually installed on their PC.

* Unused installations of software that is licensed per PC/server it is installed on.

* Power users who really need a piece of software versus less confident users that might need more training.

Autodiscovery still needs people to interpret and investigate the results, but when teamed with a decent usage tracking tool it can make the administrator's job a lot easier.

[cmdbmaverick]

Many of these tools come at a significant cost. This is true in both procurement and implementation and then the ongoing costs of applying process to use all the features you've been sold. What's wrong with having to apply some good old fashioned technical anlysis to your data. Use an open source tool called nmap, and write your data to a mysql database. See CMDB.info for detailed build instructions for an open source CMDB and just build the nmap components if all you want is the auto discovery. Lots of other open source tools are detailed here to assist in the overall performance of your infrastructure. Including OCS a desktop asset tracking software which reports on installed software on your devices, it can also be used to push software packages. Also Nagios Systems Monitoring Framework, reports everything from current availability thresholds through to trends and service levels, alerts , service groups, Host groups, etc. There is plenty there to keep you informed. Currently looking at an update to state last used date for a desktop application to enable some license harvesting.