It is not uncommon that we hear from a prospect some variation of “We already have a tool that does discovery.” However, as of yet, we haven’t run into a situation where this wound up being true.

All of the discovery tools on the market are asset-focused. Their purpose is not necessarily to help operations. In order to help operations, the relationship between components – and sometimes many components – must be understood within the context of how these related components combine to power business services.

This is not to suggest that there’s not a valid case for asset/component management. In fact, there are several valid use cases for an asset-focused discovery tool. An asset-focused tool may help you effectively manage software license compliance, or keep track of the software deployed in a data center. But asset management and service-centric management are two very distinct end goals, and require two very distinct tools.

But there are tools out there that pick up where asset or component focused discovery ends, and ties those components into the business services that they enable.

Take the analogy of a car. If an asset-focused discovery was performed on a car, you’d find out that the car has a door, a steering wheel, a transmission, an antenna, hood, intake valve, etc. You’d wind up with a list of all of the individual components that comprise a car. And this can be an important body of knowledge for any number of purposes. But it is not going to provide meaningful insight into the operational viability of the vehicle.

Our perspective on this topic is rather than starting with the components, first start with the system that the components power.

Using the car analogy, first start with the drivetrain (e.g., the “service” of delivering power to the driving wheels) and discover the individual components included within that service, such as: torque converter, transmission, propeller shaft, etc. So, you may first map all of these components to the drivetrain “service” and then monitor them from the perspective of the overall service. So if the transmission were to fail, the “user” would know that the drivetrain was being impacted. Or, conversely, if the drivetrain were to fail, the user would then be able to isolate the root cause of the failure to the individual components that power it.

See the difference in this top-down approach? It may be subtle, but the impact can be massive. An asset-focused tool just cannot be harnessed for the same use cases as a tool that ties those assets to services or systems. It can be summarized in the difference between these two hypothetical conversations between you and a member of your IT team.

Using an asset-focused discovery and monitoring tool:

IT Team: “This router died.”

You: “What does that mean?”

IT Team: “I’m not sure. Has anyone called to complain about anything yet?”

Using a top-down approach for a service -focused discovery and monitoring tool:

IT Team: “The login portal is down because this router failed.”

You: “How long until functionality is restored?”

IT Team: “Should be back up ... now!”

Again – asset management is a valid use case and an asset-focused discovery tool will satisfy that use case in the majority of deployments. But tools that focus on the assets as opposed to the services are not equipped to help bridge the gap between IT and Operations. Two tools. Two purposes.

In short: no, you really don’t already have something that does this.

Tom Molfetto is Marketing Director for Neebula.