The CMDB

The data basis for your company
When a company grows, its (IT) structures also become more complex. This is the point where a Configuration Management Database (CMDB) is the solution.

Try i-doit pro now

What is a CMDB?

A Configuration Management Database is a central database that contains all the relevant information about the IT infrastructure’s hardware and software components, which are used by IT services. Such components include, not only servers, software, and network connections, but also information about location and users, as well as licences and guarantees.

The CMDB shows the relationship between the components, providing an overview of the interrelationships and dependencies between all components, as well as making it possible to view them from different angles.

The advantage: even if individual devices are widely dispersed and the associated data comes from a large array of sources, a CMDB can be used to manage them all in one place.

How to build a functioning CMDB

CMDB projects are not something that can be "simply" completed. And because they are often demanding, many myths and legends surround these projects.

In this whitepaper, we'll dispel the seven biggest myths about CMDB projects. Here you will find valuable tips on how to build a functioning CMDB in your company.

Get it now

Introduction of a CMDB

When implementing a CMDB software in an organisation, it is essential to first define its requirements. What exactly does your CMDB need to do, and how will it serve your organisation?

Is it primarily about support in day-to-day IT operations, such as transparency, traceability and being prepared for an emergency? Should ITIL processes such as configuration and change management be supported? Are you concerned with adhering to compliance regulations, such as setting up an Information Security Management System (ISMS), reports for an audit, or is the CMDB to be used as a building block for ISO 27001 certification?

To make the project successful, you should make sure that not only management benefits from the introduction of a CMDB. Ask your entire team which processes should be optimised. If everyone sees their own benefit, the motivation for documentation will be higher and the project will be more likely to succeed.

The next step is to determine which information should be documented in the CMDB, by whom and for what purpose. “Everything” is not an acceptable answer. You need a plan. Important considerations include:

Who has which requirements for the CMDB
Who maintains the system?
Who defines the data?
Who takes care of processes?
Which data sources are reliable?
Who keeps the CMDB’s data up-to-date?

Take the time to plan this. Of course, there will always be changes that you need to include in the plan. However, it is important that you carefully consider whether each change is necessary. If the change is introduced, document it and review all related considerations, such as processes and the responsible parties.

Building a CMDB

But what happens once the plan for the CMDB is in place? Where do you start with such a project, how do you prioritise? For the start, a delimited system is recommended: an entire IT service or a CI class such as virtual servers or a business application. However, spatial delimitations such as a server room or the contents of a rack are also possible.

Before you start choosing a suitable software for your CMDB, you should consider the requirements of the ITIL rules and regulations

Federation: The software should make it possible to create a central CMDB from distributed data sources via any interfaces.
Reconciliation: It must be possible to reconcile existing data and information with updated data, as IT components may be documented differently in several sources.
Mapping and visualisation: A graphical representation of dependencies and relationships makes it possible to identify dependencies more quickly. For example, it is possible to map actual data to a target data set with the help of validation rules (target/actual analysis).
Need for synchronisation: Changes within the individual data and information sources must be synchronised in the central CMDB.

Relationships and dependencies in the IT infrastructure can thus be easily recognised and legal and contractual provisions can be checked via automated target/actual comparisons.

The CMDB thus serves not only as an inventory tool, but also for planning and analysis, optimising maintenance processes and minimising risks in the entire IT operation.

Responsibilities and roles in the CMDB project

Documenting your data and components is an important and hefty task. Be aware that building a CMDB involves a tremendous amount of effort and should be handled like a project.

For this purpose, it makes sense to have an official project manager who monitors the achievement of the defined process goals.

For the system’s maintenance, its integrations and data imports, it’s recommended to have a technical person, who is responsible for these tasks. They keep the technical part up-to-date and train new personnel in the technical implementation and operation.

Someone else should be responsible for developing methods to ensure that the CMDB is up-to-date and of a high quality, but also, for example, for prioritising the implementation of different use cases and discussing them with the persons responsible for implementation.

However, those who document in the CMDB and feed it with data are different people. And they are the heart of your project, because your CMDB stands or falls with the maintenance and how up-to-date your data is.

Your team consists not only of IT specialists, but also of database administrators, developers, and possibly also personnel from completely different departments who maintain your information in the CMDB. A good approach is therefore to divide the CMDB sensibly into (specialist) areas and to assign responsibility for managing the CMDB to people with the necessary expertise.

Automated maintenance of CIs through data integration from various sources

The integration of data from secondary or third-party systems is often a useful supplement to the recording and maintenance of CIs. A lot of information is already available in the company and is constantly managed by departments or employees. Here again, the sub-processes from configuration management are important.

Identification: Which data is already managed by which systems?
Control: Which data must be synchronised into the CMDB; when and how often?
Auditing: Which changes through the automations have to be tracked and traced?

The first step should be to check which systems & services are used and also where data such as reports and documentation are stored. By creating a Configuration Management Plan, you already know which data you need in the CMDB. By reconciling this with the systems in use, you can now easily match which data is automatically generated and maintained by systems.

These can be, for example, the following systems:

Monitoring: Live data from systems, software and services. Every change to the systems can be automatically transferred to the CMDB. This not only significantly reduces the documentation effort for employees, but also means that the CMDB always has highly up-to-date information.
Discovery: Discovery tools can be used not only to determine system information from existing devices, but also to identify new devices in the infrastructure. Here, too, up-to-date information is constantly transferred to the CMDB.
Active Directory: Information about users, computers and groups can be synchronised via a connection to the Active Directory. This is especially helpful when group memberships or user information changes, so that this information is also available in the CMDB. For example, a changed phone number of an employee is also available in the CMDB a few moments later.
HelpDesk and Service Desk: Existing tickets can be linked to CIs in the CMDB to assist with troubleshooting and analysis. Support staff thus receive all information about the affected CI with just one click and can respond to faults even more effectively.
Import of reports and tables: The regular import of e.g. CSV files can also be used for the maintenance of CIs. Whether this data is provided by an internal department or an external service provider is irrelevant.

Now it must be checked how this data can be automatically transferred from the respective system to the CMDB. The i-doit CMDB already offers many interfaces for connecting tools and services. Nevertheless, you should think about how often the data should be synchronised. This is the only way to ensure that you also achieve the quality in the CMDB that you and your employees need.

Auditing the imported data is unproblematic if configured correctly. Every change is recorded in the CMDB logbook and can be distinguished as such from changes made by users via profiles.

CIs and Assets – What are the differences?

If you have dealt with (Service) Configuration Management, you will have noticed quickly that Asset Management forms the basis for it. Configuration Management describes CIs, Asset Management talks about Assets. So what are the differences? At first glance, both seem to document objects with their respective properties.

The recording and documentation of an Asset is done from a commercial point of view. This involves accounting, monetary or financial information. A CI is located in IT operations and administration. It focuses more on the operationally relevant information such as hardware, software and required services. The intended goals of the two management systems are therefore different due to the requirements.

Configuration Items as Data Sets of a CMDB

The first question is obvious: What is a configuration item?

In configuration management, the CI (as it is commonly abbreviated) is the atom, the smallest indivisible unit. Here, the CI must not be confused with a real device. It is the mapping of the device within the CMDB. Sometimes we also talk about a configuration object. In i-doit, we simply refer to CIs as "objects".

The term "configuration" is somewhat misleading here. We are not talking about real configurations of real devices. Rather, the term stands for the representation of the mutual dependencies of the stored objects.

From the CMDB's point of view, a configuration item (CI) is first of all an object. This can be anything that is necessary for the operation and maintenance of IT and business processes. The workstation PC, the printer or the telephone are usually stored as CIs. Objects related to the devices are also stored in a CMDB as CIs. This applies to invoices, maintenance contracts or operating manuals. Finally, servers, buildings or people are also created as items in the CMDB. These CIs can be assigned various properties.

A classic application example of this:

A classic application example of this:
A server was created as a configuration item. This CI is now assigned various technical properties such as CPU, RAM and storage, but also logical properties such as the persons responsible, the location and the software. The item “Server” was therefore configured by us with information from various sources, and in doing so, became a Configuration Item.

The advantage of this approach is the huge variety of information that we can store centrally. This enables us not only to simply record information, but also to display relationships and dependencies between the respective CIs.

CIs and Assets – What are the differences?

The CMDB as the foundation for ITSM

The CMDB is often seen as the central element of IT Service Management (ITSM). This is mainly due to ITIL, the IT Infrastructure Library. In this set of best practices for process optimisation, configuration management is presented as an essential aspect of ITSM. With the help of the documentation of all components, their data and relationships, a model of the IT infrastructure of the entire company is created.

That’s why a CMDB is virtually indispensable when you want to implement IT Service Management. People, processes, and systems can benefit from the extensive information contained in the assets. This in turn ensures the long-term success of the company’s goals, not only within the IT department, but in all areas of the company.

Benefits and possible applications of a CMDB in the company

There are many possible uses for an enterprise CMDB. In addition to complete IT documentation, it is used primarily when you need to map the product life cycle of devices. In doing so, all states are documented sustainably and support the IT department in identifying recurring faults.

The CMDB can exchange data with various systems as part of the IT Service Management. A monitoring solution receives the information about the systems to be monitored from a CMDB. At the same time, in turn it reports back about the status of the respective assets. This status is stored in the CMDB.

Discovery software regularly scans the network for connected devices. The information in the corresponding configuration items of the CMDB is then updated with the data acquired.

The service desk benefits from a CMDB in a special way. If, for example, the monitoring system reports a malfunction in a system, a corresponding ticket can be opened automatically. This ticket not only contains information about the type of fault. The CMDB also provides all available information on the affected system. Conversely, a service desk employee can access the CMDB data in the event of a fault report. They can therefore quickly obtain a complete overview of the faulty systems.

Other server and directory services such as Active Directory also provide important information regarding users, computers and groups.

The CMDB thus contains information from all areas of your company. It then consolidates the information in the CIs, establishes connections between them and makes this information centrally available to your employees, departments and managers.

The positive effects of a CMDB on IT

A major problem in many IT departments is the fact that information about a particular device is stored in many different data repositories. Technical information may be stored in plain text in an Excel spreadsheet. Invoice documents can be found in network drives in the accounting department. And contract documents are accessible as a reference via the ERP system.

With a CMDB, your team no longer has to wade through dozens of tools to find the information they need. It doesn’t matter whether you are looking for information on a server from monitoring, an invoice from financial accounting or the last correspondence with the technical department in order to be able to remedy a malfunction. All information and documents are in one place – the CMDB.

This not only minimises the time for internal searches, but also the idle time in processes. After all, these always occur when required information is not available and a third party has to be waited for in order to proceed.

The greatest added value, however, is the reliability of information. Since there is no longer any local documentation and all changes are documented in the CMDB, highly up-to-date information is always available for employees in all departments. The eternal comparison between different documentation data to determine the current version is thus a thing of the past.

An always up-to-date CMDB:

can be used for optimising and planning the IT infrastructure
provides basic data for the visualisation of IT concepts and IT relationships, and
can show performance bottlenecks and mutual dependencies.

How the CMDB helps with change management

Change management has been an integral part of project management for a long time. But it is also essential for the administrators of complex IT infrastructures. Change Management describes the process of how changes to systems and components are carried out, which people are involved, and who is responsible for authorising the desired measures.

Change Management’s background: to avoid disruptions and failures of IT services due to changes.

The first step is to check which systems are affected by the changes. With a CMDB, you have already defined all dependencies and relationships between your CIs. Based on this information, you can more efficiently plan your project and assess the associated risks. In the case of a change, not only the changes actually implemented are checked, but also who implemented and authorised them.

By constantly planning and controlling changes, you ensure the availability of your IT services and thus guarantee your company’s performance.

Configuration Management

Configuration Management is implemented for the identification, administration and documentation of all Configuration Items (CIs) and their relationship to each other. It is often presented in a more complicated way than it actually is. By dividing it into the following 3 sub-processes, Configuration Management becomes much more tangible and, above all, implementable.

Identification and capture of CIs
The first step is of course to identify which CIs you want and need to capture. Your departments, specialists and managers can usually quickly tell you which information your company needs to have. All you have to do is combine the identified information into a configuration management plan.
Controlling the CIs
Every CI goes through its own personal lifecycle. Defective ones may occur, components may be replaced or new software may be installed. Once configuration items have been entered, they must be continuously maintained. It must therefore be precisely defined who identifies and also documents these changes. This person/department must of course also have the necessary competencies to be able to classify changes. Finally, motivation is also a decisive factor. An employee who is technically capable of maintaining a CI, but otherwise has no contact with it in daily business, has significantly less motivation than a service owner and his team who must rely on the existing data on a daily basis and know which information is required.
Verification and auditing of CIs (Configuration Items)
The information in the CMDB forms the basis for a large number of planning and decision-making processes for specialists and managers. To ensure that the existing data can be trusted, regular verification and auditing of the data is necessary. However, the aim should not be to accuse employees of incompetence, if they may have simply forgotten to document changes in the stressful project business, but above all to uncover gaps and correct them. The primary goal must be to always have up-to-date and verified data. If you notice that your employees and colleagues increasingly fail to record changes in a timely manner, third-party tools such as monitoring or discovery tools can provide the necessary information on a regular and automated basis.

Configuration Management as a rescue for change processes

When you introduce change management processes, you cannot avoid configuration management. The advantages greatly outweigh the minimal effort.

Configuration Management expands the existing IT documentation. A change to a server or switch can, under certain circumstances, result in faults that aren’t detected for days or weeks. Although the “Change” describes which changes are made, it does not describe how the server or switch was configured before the change. With Configuration Management, you can easily return to the last known working configuration of your CIs to fix problems and reschedule your change.

Of course, this is not only applicable to physical devices and products, but also to software and databases. There are always prerequisites that must be met for software to run. You must therefore define exactly which components are required in the respective version for an error-free operation of the software, in order to configure a build (Build Management).

Otherwise, new versions of programming languages, database management systems, or software packages that are required in dependency, can negatively affect the functionality of the software. Therefore, it is also important to define an executable configuration that you can return to if necessary (Version Management).

Last but not least, this simple and clear definition also allows you to determine exactly which software has been completed for internal or public release and which requirements the systems must meet to be able to run the application (Release Management).

CMDB for the effective use of information

The focus of a CMDB project should always be on the effective use of information. The CMDB should not be understood simply as a database. It is the central point of contact for all IT operations topics and the provision and preparation of information. The information that is needed and in what quality should be identified in advance. A CMDB thus provides all the information for the organisation. What at first sounds like only a small added value is, however, of much greater importance in depth.

IT operations and processes
IT operations are significantly dependent on information. Not only which systems operate in the infrastructure, but also the changes to these are essential for administration and ongoing operations. The CMDB provides a 360° view of the entire IT infrastructure through the availability of information and the representation of dependencies and relationships.
Auditing of existing information
Validated information is required for planning and changes to the infrastructure. Not only can the quality of the data be recorded via a CMDB, but it can also be audited on a regular basis. This means that gaps in the documentation can be quickly identified and poor quality can be quickly corrected.
Identifying and minimising risks
By fully documenting the infrastructure and linking information, risks can be identified more quickly. Whether configurations, networks or software patches. With a CMDB, you have all the information you need to implement effective risk and security management.
IT costs and potentials
In addition to hardware and software information, the focus is naturally always on the associated costs. By recording all assets, you are able to evaluate costs e.g. by department or location. In this way, you can identify potential savings, combine software and services and use them to optimise the system landscape.
Data protection and information security
The Basic Data Protection Regulation and the Federal Data Protection Act place high demands on information security as well as the collection, processing and storage of data. A CMDB makes it possible to control and restrict access to information and data.
Replacement of isolated applications
It is not uncommon for isolated applications to be set up from effect. A solution has to be found quickly, but whether this solution represents actual added value for the organisation has to be examined individually. However, a CMDB can often take over the information from these isolated applications and thus provide more transparency within the organisation. If necessary, it can even be decommissioned after the data transfer and thus save costs.