Why automated discovery alone does not guarantee a good CMDB

The first part of this article series focused on a common issue in CMDB projects: the question of the tool is often raised too early. The second part builds on this and examines a related issue. Once the CMDB’s data model, processes and integrations have been defined, the practical follow-up question arises: How can Configuration Items and their relationships be kept up to date?

In many cases, automated discovery is the answer. The underlying assumption is understandable: if systems are automatically detected and read, maintaining data in the CMDB should become significantly simpler. In practice, however, while automated discovery is relevant, the quality and usability of a CMDB do not depend on it alone.

In simple terms, an automated discovery tool consists of four functional building blocks:

Furthermore, many enterprise discovery tools already support common technologies across different levels of the infrastructure and can be extended in many cases.

The effectiveness of automated discovery depends on how standardised the elements to be captured are. In practice, corporate infrastructures are rarely fully standardised, which causes problems. Customisations and discrepancies are frequently found at multiple levels, including the operating system, middleware components and interfaces, and operation-specific configurations.

Accordingly, the standard logic of a discovery tool quickly becomes ineffective. Two patterns typically emerge. Either the existing logic does not deliver the required information, or it generates large amounts of data that do not provide sufficient added value for the CMDB.

Both scenarios require additional effort, sometimes substantial, as the discovery mechanisms must be adapted, extended or supplemented by other sources. Furthermore, updates to the discovery tool can affect customised areas, resulting in the need for ongoing maintenance.

Our experience with CMDB projects shows that, when the standard mechanisms of a discovery tool are exhausted, it is generally not worthwhile continually adapting the tool to the specific conditions of the infrastructure in question. It is more sensible to work with the tool and supplement missing information from other reliable sources.

Rather than relying on a single discovery tool, it is often more effective to consider a CMDB Discovery Framework. Several aspects are relevant to building such a framework.

The first step is to identify the relevant data sources. It is not necessary to collect every piece of information from scratch if it is already reliably available in other systems. For this reason, reviewing existing tools or platforms is helpful. Depending on the environment, an agent-based, agentless or combined approach may be most appropriate. The key is to use the most suitable source for the required information in each case.

Security specifications can have a stronger influence on discovery initiatives than the tool’s logic. Therefore, the protocols to be used and the access rights available – including permissions for technical queries – should be clarified at an early stage. If restrictions are in place at this stage, it is advisable to return to the initial view and architecture. Often, this will require planning alternative data sources or collection methods.

The Pareto principle often applies to discovery initiatives. For example, around 80% of the necessary information relates to just 20% of the relevant CI types. This is precisely why it is important to define early on which attributes actually need to be maintained. Without this limitation, the effort required increases rapidly, but the business value does not increase in proportion.

A discovery framework is an ongoing task because all maintained data must be regularly reviewed to ensure that it remains usable for subsequent processes. In addition to being complete, high-quality data must also be timely, consistent and traceable.

The processed data must be transferred and consumed in a technically traceable manner. To this end, it is recommended to have a mechanismin place to indicate whether the transfer was successful and whether the information arrived in the intended target structure. Only when this final stage is reliable can data collection contribute dependably to maintaining the CMDB.

In this context, while the choice of tool is important, it is not the only decisive factor. Generally, different solutions can deliver comparable results if deployed in accordance with requirements.

Whether a commercial or open-source solution is more suitable depends less on the quality of the tool itself than on the requirements of the CMDB in question, the existing infrastructure and the organisational framework.

Automated discovery makes it easier to collect and update CI data. However, this does not automatically result in a reliable and usable CMDB. Standard mechanisms are limited, particularly in infrastructures characterised by customisations.

It is therefore sensible to consider the bigger picture. Treating discovery as an independent task with clear data sources, a defined scope, aligned security specifications, continuous quality control and reliable integration enables CMDB data maintenance to be organised in a much more targeted manner.

The third part of this series will cover the conceptual and terminological classification of core structures in the CMDB environment, including the CMDB, CMS and SKMS.