A CMDB Without Discovery Is Just a Database

The importance of discovery comes from what it provides to the users of the Configuration Management Database (CMDB): trustworthy data and greater speed to value. Without discovery, the CMDB database is built by feeds and data entry, which can lead to errors that affect confidence in the data.  Trustworthy data is also what auditors demand, and leveraging Automated discovery for IT audit ensures that the CMDB’s accuracy is continuously validated by automated scanning rather than being dependent on manual updates that inevitably fall behind.

This manual approach is one of the most common root causes of CMDB failure, as data entry errors compound over time and eventually render the database unreliable for incident, change, and compliance workflows.

This is precisely why discovery capability is a top differentiator when evaluating the Best CMDB Tools, as platforms with built-in automated discovery deliver trustworthy data from day one rather than relying on manual population.

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.

This is the exact trap most Atlassian CMDB deployments fall into. Because the Atlassian CMDB (Jira Service Management’s assets-based configuration model) does not ship with native enterprise-grade discovery, teams often try to seed it through CSV imports, manual entry, or one-off scripts. The result is the same pattern this article describes: a directory of names that looks populated on day one and drifts into fiction by quarter-end — which is why pairing any CMDB, Atlassian’s included, with continuous automated discovery is non-negotiable.

Trustworthy data

IT Discovery provides a means to ensure that the data in the CMDB database is accurate by identifying the devices on known networks and information pertaining to their configurations (technical attributes).  Organizations evaluating platforms like Easyvista CMDB should verify whether the platform’s native discovery engine delivers the automated, multi-protocol scanning needed for trustworthy data, or whether a complementary discovery tool like Virima is required to keep CI records accurate.

Using a key attribute, like the item’s serial number or license key, this information can be used to locate the asset in an IT asset management database and complete the non-financial information about the asset, beginning the process of turning that asset into a Configuration Item (CI).

Network monitoring tools or discovery applications can perform discovery. Dashboards facilitate merging, deleting, or accepting duplicate records. Thus, resolving potential issues during the CMDB discovery results in commitment. Machine learning accelerates this process by building and automating rules to process data.

Automated Discovery tools also work with business Service Mapping applications, which help document relationships between configuration items, generally up to the technical service or application level. At this point, we only use human intervention to enter logical CIs, such as business services, and to map applications and technical services to the supported business service.

The result is a highly reliable database that can be trusted and used to support Service Management practices with confidence.

CMDB database: Attribute validation

Discovery also includes attribute validation, i.e., ensuring that the data within a CI record is trustworthy. During asset management, organizations tie a purchase-generated asset record to the Configuration Management Database through the discovery process. This validation step is a critical component of any CMDB audit, where teams systematically compare discovered attributes against expected configurations to surface drift, missing records, and data quality issues before they impact downstream processes.

During discovery, the system validates that the delivered hardware configuration matches the one initially ordered for the asset. There are several important aspects to this step:

• Discovery validates the proper configuration of the purchased item. Thus allowing the organization to follow up with the vendor in case of under-configuration or incorrect configuration.
• 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.
• More accurately documenting software, operating systems, and their patch levels enhances root cause analysis for issues caused by specific versions.

Discovery of unauthorized devices and applications

After validating the accuracy of the CMDB database and implementing a program to keep it updated, the CMDB becomes a source for identifying devices or device changes. It does this without an accompanying change request when combined with monitoring and discovery. In this way, the change enablement practice can truly secure the enterprise.

A few examples:

• 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 continuously 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.
  
  This is where a CMDB communication view extends what basic discovery delivers.
  
  A CMDB communication view plots real host-to-host traffic flows on top of your CMDB, so unauthorized devices that speak on the wire but have no CI record light up immediately, and open ports that were never supposed to be open stop hiding between scans.
  
  It turns “the CMDB does not know about this machine” into “here is the machine, here is what it is talking to, and here is the port it opened.”
  

Change enablement evolution

As the change enablement practice has evolved, 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 the discovery, unauthorized changes no longer pose the threat to the environment as they used to, since discovery is able to identify them, and risk assessment can be performed, with appropriate action taken.

Proactive Operations

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 can occur:

A repetitive issue with a particular hardware model and a good Configuration Management Database enables an organization to find the install base for that model and proactively replace the item before it fails. This is a great reason to eventually take the CMDB database 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 database to identify accompanying CIs that meet the criteria and then prioritize the mitigation activities.

The repair history of a CI can be used to determine equipment that needs replacement or the CMDB management 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 that discovery provides to the CMDB.

CMDB database: Time to Value

Building a CMDB database manually and mapping services is an extremely time consuming and inaccurate endeavor. This is a common pain point for organizations using legacy platforms like BMC CMDB, where manual processes and complex customization can slow down time to value. CMDB Discovery may come with a price tag, but it’s payback comes in several forms:

Critical services that could take months to document manually can be discovered and mapped in only a few weeks, bringing almost immediate value to an organization as the benefits of the accurate CMDB database can be reaped for the most critical services.

All infrastructure and software within each data center can be added far more quickly using automated 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 IT Asset Management (ITAM) perspective but also ensures that IT can look at the unexpected equipment and software found and ensure that it is benefitting the organization rather than exposing it to risk.

The 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.

Also Read: The role of your CMDB in effective IT management

Manufacturing and logistics need similar abilities 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 database.

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 evolve, the human intervention to manage a fully-discovered enterprise will no longer be a barrier to inclusion.

Also read, Is 2020 the year of The Configuration Management Database (CMDB)

Virima’s IT Discovery features can automatically discover and map your critical IT resources and the interconnections that link them to one another, your applications and services, and your users.

Virima is here to help. Get started with us!

Contact us today to schedule a demo and explore the possibilities!