CMDB management with i-doit: Improve data quality and IT processes

CMDB management with i-doit establishes a reliable foundation for IT operations and management decisions. This article shows how to build your CMDB in a structured way, integrate data sources, and ensure long-term data quality. You will also learn how reporting, change management, audits, and contract management work together on the same database.

Table of contents

1. CMDB management: the foundation for reliably documented IT
2. Why use i-doit for CMDB management?
3. CMDB data integration: connect data sources and prevent conflicts
4. CMDB data enrichment: link systems with services, owners, and contracts
5. Measure and improve CMDB data quality
6. Reporting: derive concrete management tasks from CMDB data
7. Changes: connect changes to documentation
8. Support audits and contract management
9. CMDB management: redefine and purposefully steer IT documentation with i-doit

CMDB management: the foundation for reliably documented IT

A Configuration Management Database, or CMDB, documents configuration items (CIs)—such as servers, applications, and IT services. In addition to their properties, it captures dependencies and relationships between these objects. This makes it possible to trace which application runs on which server and which services depend on it.

CMDB management encompasses the rules and processes used to capture, verify, update, and utilize this information. This includes responsibilities, interfaces, and handling changes throughout the entire lifecycle of a CI.

The CMDB provides the technical foundation. Whether it delivers useful answers depends on how your processes are structured.

Why use i-doit for CMDB management?

With the i-doit CMDB for structured CMDB management, you document devices, applications, locations, and services as well as their interrelationships. The CMDB Explorer visualizes captured dependencies and relationships graphically. This enables operations and management to work on the exact same database.

A practical use case: Before maintaining a server, the IT team checks which applications and services are connected to it. Management gains a reliable basis for evaluating affected business workflows and maintenance windows.

This approach aligns with the objective of service configuration management according to ITIL: providing reliable configuration information whenever it is needed.

Which decisions does your CMDB need to support?

Anyone looking to implement a CMDB should first define which decisions it needs to support. A well-defined use case is a great starting point:

• Which systems are affected by scheduled maintenance?

• Who is responsible for a business-critical application or process?

• Which devices will lose vendor support in the coming months?

• Which maintenance contracts are expiring soon?

For the first question, you primarily need dependencies. For the last one, you need contract data and its assignment to the affected objects. The use case dictates which information must be documented first.

This keeps CMDB management feasible even with limited resources.

Define object types, attributes, and relationships

A simple data model can look like this:

Limit mandatory fields to information required for the specific use case. Every additional field requires a source, a maintenance process, and a clear benefit.

In i-doit, you structure documentation using object types, categories, and attributes. Proper documentation also includes clear field definitions. For example, specify whether "Owner" refers to technical operations, business responsibility, or contract management.

Define responsibilities

Successful CMDB management requires someone to coordinate the data model and quality rules. The operational maintenance of assets can be distributed across multiple teams.

Define for each object class who verifies data, who fixes errors, and when updates take place. A server team might be responsible for technical server data, while procurement or accounting maintains contract runtimes.

When building a CMDB, plan these responsibilities right from the start.

CMDB data integration: connect data sources and prevent conflicts

Determine the leading source for each attribute

Technical and organizational information usually resides in multiple systems—such as discovery, endpoint management, monitoring, MDM, or directory services.

For CMDB data integration, you should define which data source is permitted to deliver which attribute. A discovery tool can update the detected operating system, whereas the cost center typically comes from an accounting or billing tool.

If two data sources write to the same field, a priority rule is required. Otherwise, an import could overwrite accurate information with an outdated value.

CMDB management here means consciously controlling data flows.

Identify objects reliably

A device name can change. An IP address can be reassigned. Therefore, check for each object class which attributes allow for reliable identification.

For physical devices, the manufacturer and serial number can serve as suitable identifiers. For cloud resources, the resource ID and account context are typical candidates. An internal CMDB ID then links the associated information.

CMDB data integration also involves rules for duplicates, empty fields, and missing detections. If a device is not detected once, it should not be deleted immediately.

Log import errors and assign their resolution to a specific team. An unnoticed data import failure will cause the CMDB database to slowly become obsolete.

For technical inventory data, the integration of i-doit and JDisc Discovery offers a practical starting point. JDisc detects devices and technical relationships; the integration transfers this information into i-doit. Which data is imported and updated should align with your data model.

CMDB data enrichment: link systems with services, owners, and contracts

Automated discovery delivers a wealth of technical information. However, operational decisions often lack service context, business ownership, or criticality.

Through CMDB data enrichment, you add these relationships. A discovered server, for example, becomes a system hosting an application, supporting a business service, and being linked to a maintenance contract.

In i-doit, you can document these details as dependencies or relationships. This enrichment can be performed manually, via additional interfaces, or through validated mapping rules. The crucial factor is that origin and responsibility remain transparent.

An example: Discovery detects a virtual machine along with its operating system and running applications. Through CMDB data enrichment, you add the organizational context: Which business process does the application support? Who is responsible for running it? What would be the impact of an outage? And which support contract covers the system?

Prioritize these additions for business-critical services and their dependencies. This allows your CMDB documentation to help plan maintenance, troubleshoot incidents efficiently, and evaluate operational risks.

Measure and improve CMDB data quality

CMDB management requires verifiable quality rules. The sheer number of documented objects says little about whether your teams can actually work with them.

Valuable audit criteria include completeness, timeliness, uniqueness, and plausibility. Relationships also require dedicated checks: An existing server record offers little value during an impact analysis if its applications are not mapped.

For i-doit, you should derive specific checks from this: for instance, servers without an assigned owner, production applications without service mapping, or contract objects without a duration. Define the required evaluations based on your documented fields.

These metrics, for example, are well suited for custom quality reporting:

Clearly define the scope of assets considered and the calculation formula for each metric. Retired devices have different requirements than production servers.

Populated fields are also no guarantee of accurate content. Supplement automated checks with targeted spot checks.

Improvements in CMDB data quality should result in actionable tasks: with an assigned owner, a due date, and subsequent review. This embeds quality maintenance into regular operations.

i-doit supports reporting with its integrated Report Manager. Through auditing and reporting with i-doit, CMDB data can be selectively combined, filtered, and centrally provided as reusable evaluations.

Reporting: derive concrete management tasks from CMDB data

Which systems need to be replaced next quarter? Where are maintenance contracts expiring? And which business-critical applications still depend on a server lacking vendor support? With targeted reports in i-doit, you turn documented information into a foundation for planning and prioritization.

An example: A report highlights all servers whose support ends within the next six months. If you add the applications running on them, the affected services, and their owners, the need for action can be definitively assessed. A test system can be prioritized differently than a server running the central ERP system.

Leadership receives an overview of investment requirements and operational risks. The responsible IT teams can prepare replacement procurement, plan migrations, and clarify open responsibilities based on concrete assets.

Recurring reports also make progress visible: Which systems have already been replaced? Which tasks are still outstanding? In this way, reporting supports CMDB management with i-doit from the initial assessment all the way to implementation.

Changes: connect changes to documentation

In everyday operations, the CMDB is used in tandem with an integrated ticketing system:

1. Record the change as a ticket and link the affected CIs from i-doit.

2. Use the documented dependencies to verify which applications and services are affected.

3. Plan and approve the change in the ticketing system, and document its implementation.

4. Update the modified attributes and relationships in i-doit and verify them before resolving the ticket.

An example: The IT team plans an operating system upgrade on a server. The affected system, implementation steps, and maintenance window are recorded in the change ticket. i-doit provides the context: Which applications are running on the server? Which services depend on it? Which owners need to be consulted?

After implementation, the team documents the outcome in the ticket and updates the operating system version in i-doit. This ensures that what changed remains traceable, while the CMDB continues to reflect the current state.

CMDB management thus becomes an integral part of daily work within the ticketing system. Define a clear completion criterion for this: A change is only completed once the affected CMDB data has been verified and necessary updates have been made.

Support audits and contract management

Use IT documentation for audits

During an audit, information must be traceable. Therefore, record where data originates, when it was verified, and who is responsible for it.

In i-doit, responsibilities and object information can be evaluated; changes to the documentation are transparently recorded in the logbook. Structured CMDB documentation thus simplifies compiling object lists, responsibilities, and change histories. Agreed audit criteria can be verified using reports.

Which audit evidence is required depends on the specific audit. Plan which information and histories you need to retain based on these requirements.

Link contract deadlines to affected assets

With contract management in i-doit, you link contract information with the associated objects and owners. In addition to the term, the technical scope is equally vital. Map maintenance and support contracts to the devices, applications, or services they cover.

Document contract owners, cancellation deadlines, and the storage location of contract documents. Set up automated notifications tailored to your requirements.

Another form of CMDB data enrichment is mapping support terms or agreed response times. This allows you to verify prior to a renewal which systems are still in use and which service tiers are actually required.

CMDB management: redefine and purposefully steer IT documentation with i-doit

A CMDB must be able to answer questions directly:

• Which systems keep your business processes running?

• Where is action required?

• And what are the consequences of a planned change?

With i-doit, you bring together technical information, responsibilities, contracts, and service dependencies in a centralized CMDB. This gives your team the clarity needed to make well-informed decisions.

The CMDB Explorer visualizes dependencies, reports deliver answers to specific management questions, and integrations with discovery and ticketing systems embed your documentation directly into daily operations. This turns CMDB management with i-doit into an effective tool: for predictable changes, faster troubleshooting, traceable audits, and a clearer overview of costs and contract terms.

Experience what i-doit can do for your IT: Discover i-doit for your CMDB management and schedule a demo with our sales team.

Test i-doit group software productively now.

The i-doit group is the leading software manufacturer for IT documentation, CMDB, ITSM & cabling management, as well as for ISMS, emergency management & data protection. Over 2,000 active customers trust us for their digital resilience.

Test for 30 days!