The CMDB

What is a CMDB?

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.

Where does the term "CMDB" come from?

In 1989, the Information Technology Infrastructure Library (ITIL) was developed on behalf of the British government. This work describes the ideal processes in IT. It is a guide for the organisation of information technology and a collection of best practices in IT operations. The term Configuration Management Database also comes from this work.  

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.

Keeping with the example "server":

The CI we created is directly connected to the “Microsoft Server 2019” CI. However, there are different applicable contact persons for the software than for the machine. This is not a problem for the CMDB. Due to the strict separation of objects, we can collect the exact information for each necessary CI, if we need to.

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.

Separate Assets and CIs?

Asset information is often captured in software solutions for accounting or billing. However, this data is also useful for IT operations. Therefore, the solution is to bring them together in the CMDB. This gives the company a consolidated view of the entire IT infrastructure. Since CIs can be extended in many ways, consolidation from different data sources is not a problem.

IT asset managment and CMDB – are there differences?

The biggest difference between CMDB and IT asset management lies in the sources of information, data storage and the presentation of the actual and target state of the IT infrastructure.

IT documentation deals exclusively with the ACTUAL state of the infrastructure; the documentation and representation of relationships and dependencies is very limited. This is the CMDB’s strength, as it  can map these relationships with the accuracy of a pinpoint. It links both physical and logical connections between the CIs and thus provides a complete overview of the IT infrastructure. In addition, it can also display the (target) states of objects, which physically speaking, are not yet in the company. 

For example, a CI can also take on the state “In Delivery” or “Ordered” to announce its arrival in the company. Often this is important information for the timely integration of the devices into the IT infrastructure. These states are part of each CI’s life cycle and should be documented for life cycle management purposes. The CMDB does this work for you.

The CMDB as the foundation for ITSM

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.

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.

1. 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.
2. 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.
3. 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.

Introduction of a CMDB

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

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.

Great advantages by saving time and money

Now you probably see a pile of work ahead of you and wonder if the effort is really justified? Is the value of a CMDB really so great that it’s worth involving the entire IT department and many others in the organisation  to build it?

The  benefits of a functioning CMDB are, however, enormous. By creating a binding point of information, you create value: not only for the IT department, but also for other business units and management. 

Reporting from all the data in the CMDB gives you the ability to plan better. For example, you can save time and money, by calculating the expected demand for new IT purchases in the coming year. Effective reporting enables extensive savings, because data from the CMDB is aggregated and reused.

Once the CMDB has taken effect  – because data is reliably high-quality and users have experienced real help in critical situations – the benefits are obvious:  Your colleagues can  take action themselves. The CMDB is queried with scripts, data is automatically updated, and redundant data stocks are continuously reduced. The CMDB is fully recognised.