Discover your discovery options - the difference between Dependency discovery, Infrastructure discovery and Inventory discovery

For what seems to be forever, discovery was one of those universal concepts that was pretty much standard across vendors.  With few exceptions, it was nothing more than a ping sweep across a specified range or subnet to identify running devices (servers, network gear, etc.), followed by some flavor of NMAP to scan ports for running applications as well as host OS detection.  For the sake of this discussion, we'll call this Traditional Discovery.  And while this is still the basis of most discovery engines, the last couple of years have seen discovery fork into a number of variations to support new use cases.  While there is a lot of overlap in how these new discovery options are collecting data, it's the type of data they are focused on that really separates the different types.  Unfortunately, vendors like to use Discovery as an umbrella label for all of these, causing a good bit of confusion for users.  So, let's explore the various options out there.


Inventory Discovery

Predominantly seen in IT Service Management (ITSM) solutions, inventory discovery extends on traditional discovery through the use of some combination of Agents, remote scripting and API calls.  What makes inventory discovery unique is that its only looking to collect information about the specific configuration of assets and the licensed applications installed.  As a result, this method collects the least amount of information of the various new options, and typically runs less frequently.  The output of this method is typically a categorized assets inventory, how many Windows 2012 servers you have, how many disk drives are installed on each asset, how many licenses of MS Office are in use.  While this method of discovery is highly useful for Asset Management, it provides some value for Service Management.


Infrastructure Discovery

This discovery method is predominantly used in IT Operations Management (ITOM) solutions, and uses many of the same methods as Inventory Discovery.  However, the focus for this method is less on developing an asset inventory than finding what operational metrics are available from a monitoring standpoint.  As a result, this method typically won't return how many licenses of MS Office are in use, but will return a list of metrics such as CPU utilization, disk write speeds, network collisions.  Thus, the results of Infrastructure Discovery are less useful for Asset Management, but highly useful for Operations Management.  Yet, it is important to point out that Infrastructure Discovery, like Inventory Discovery, produces a flat list of individual assets, with little information regarding the interconnectivity between systems.


Dependency Discovery (a.k.a. Application Discovery and Dependency Mapping - ADDM)

This is where we're seeing the most significant changes in Discovery.  With Dependency Discovery, we actually aren't concerned with the details of any individual asset.  Instead, the focus is on how each of these systems interoperate to deliver critical applications or IT services.  As a result, most of the capabilities of Traditional Discovery aren't used; replaced by either passive network monitoring via NetFlow or sFlow or through remote scripting to identify what active connections are being made from each server or vm.  The final output is typically a map that focuses on how each asset is communicating with others.  This method probably has the least value for Asset Management, but is highly useful for Service Management, Operations Management.


FireScope's Approach

With FireScope, we actually use a combination of Dependency Discovery to build the map of critical IT Services, followed by Infrastructure Discovery on those dependencies to identify the critical metrics that should be monitored to ensure IT Service Delivery.  This hybrid approach allows us to achieve the best of all worlds, deep information on each asset, but with the context of why these metrics are important to the business.