The importance of discovery comes from what it provides to the users of the Configuration Management Data Base (CMDB): trustworthy data and greater speed to value. Without discovery, the CMDB is built by feeds and data entry, which can lead to errors that affect confidence in the data. Beyond the technical value of discovery is the fact that when combined with service mapping, the CMDB’s time to value is greatly reduced, as it begins to provide enough data to support service management processes more quickly.
Discovery is a critical means of ensuring that the data in the CMDB is accurate: it finds the devices on known networks and can add information concerning their configuration (technical attributes). Using a key attribute, like the item’s serial number or license key, this information can be used to locate the asset in an asset management database and complete the non-financial information about the asset, beginning the process of turning that asset into a configuration item.
Discovery can be performed by network monitoring tools, discovery applications, or both. Through the use of dashboards, duplicate records can be merged, deleted, or accepted, helping to reconcile any potential issues raised while committing discovery results to the CMDB. With machine learning, this process can be accelerated, as rules are able to be built and automated to process the data.
Discovery tools also work with service mapping applications, which help document relationships between configuration items (CIs), generally up to the technical service or application level. At this point, human intervention only is used to enter logical CIs, like business services, and to map the applications and technical services to the business service they support.
The result is a highly reliable database that can be trusted and used to support service management practices with confidence.
Part of discovery is attribute validation, ensuring that the data within a CI record is also trustworthy. When organizations are engaged in asset management, a purchase will generate an asset record, which is tied to the CMDB during discovery. That asset may have been ordered with a particular hardware configuration, but discovery actually validates that the configuration ordered has been delivered. There are several; important aspects of this step:
- Discovery validates that the item purchased was properly configured, enabling the organization to follow up with the vendor if the device is under-configured or incorrectly configured
- Having the right configuration information is critical to troubleshooting incidents – it’s not enough to rely on the sales/delivery information for the item as this can lead to incorrect assumptions and diagnoses
- Software and operating systems and their patch levels are more accurately documented to improve root cause analysis related for issues caused by particular versions.
Discovery of Unauthorized Devices and Applications
Once the accuracy of the CMDB is trusted and a program that keeps the CMDB updated is in place, the CMDB, combined with monitoring and discovery becomes a source for identifying devices or device changes that have been introduced without an accompanying change request. In this way, the change enablement practice can truly secure the enterprise. For example:
- An end-user in a remote location cannot plug in an unauthorized wireless device that exposes the network to intrusion.
- External vendors cannot provide turn-key applications and hardware.
- Cloud services cannot be accessed ongoingly without eventually being detected (particularly if service mapping tools are used, as traffic patterns could be used to identify the use of an external service).
- Changes to a device’s configuration cannot be made without the activity being discovered, researched, and documented.
As the change enablement practice has matured, it is looked at as a practice that enables changes to be made to a CI, whether hardware or software, ensuring those changes get properly approved and documented. Without the use of discovery tools, the change practice was used to update configuration information, so unauthorized changes contributed to the lack of trustworthy data. With discovery, unauthorized changes no longer provide the threat to the environment as they used to since discovery will identify them, and risk assessment can be performed, with appropriate action taken.
Like the use of discovery to validate CI attributes, in-depth knowledge of CIs can support proactive activities. There can be any number of different ways this occurs:
- A repetitive issue with a particular hardware model and a good CMDB enables an organization to find the install base for that model and proactive replace the item before it fails. This is a great reason to eventually take the CMDB down to the workstation and local equipment level.
- Intermittent issues related to OS patches or software version levels can be followed to incorrect patch or software versions, located and upgraded.
- Security vulnerabilities and their potential impact on the environment can be evaluated using data in the CMDB to identify accompanying CIs that meet the criteria and then to prioritize the mitigation activities.
- Repair history of a CI can be used to determine equipment that needs replacement or the CMDB and asset management data can be used to plan more proactive end-of-life refreshes.
All of this comes back to data. If there’s a bad component in a hardware model, finding all instances of that model could become highly time-consuming or impossible without the data discovery provides to the CMDB.
Time to Value
Building a CMDB manually and mapping services is an extremely time consuming and inaccurate endeavor. Discovery may come with a price tag, but its payback comes in several forms:
- Critical services that could take months to document manually can be discovered and mapped in only a few weeks, bring almost immediate value to an organization as the benefits of the accurate CMDB can be reaped for the most critical services.
- All infrastructure and software within each data center can be added far more quickly using discovery and equipment that people were not aware of will also be located, with its use and history tracked down after discovery. This leads to a far more accurate inventory from an asset management perspective but also ensures that IT can look at the unexpected equipment and software found and ensure it’s benefitting the organization rather than exposing it to risk.
organization can expand the use of the CMDB to personal computing devices,
which further supports IT’s ability to manage the environment. While data
center operations are the most critical area to secure with a trustworthy CMDB,
there is also tremendous value going beyond the data center:
- Retail environments benefit from being able to more quickly and cost-effectively manage point of sale systems and other location-based equipment.
- Manufacturing and logistics need similar ability to manage smaller warehouse equipment (clearly infrastructure would be managed, but computers used by personnel to support logistics might not).
- End-user computers could be affected by known defects and/or intermittent issues that are difficult, if not impossible, to mitigate without a CMDB.
Thus, the use of discovery enables time to value at both the infrastructure/application level and at the personal computing device-level – both of which are critical in a highly technical environment. Before discovery, taking the CMDB to this level would be unheard of, but with discovery, these capabilities simply require additional maintenance. As discovery and machine learning continue to improve, the human intervention to manage a fully-discovered enterprise will no longer be a barrier to inclusion.
Do you want to start or improve your CMDB process? Watch our webinar, “6 steps to CMDB success.”
The next in our blog series will focus on “The CMDB as a source of truth.”