The Configuration Management Database (CMDB)
The larger a company becomes, the more complex its structures become. The same is true of the IT infrastructure. The more servers, end users and software licenses are added, also adds to its complexity. It’s no wonder that things can be overlooked and errors can occur – and this is simply because the important information was not available at the right moment. This is where a Configuration Management Database (CMDB) can help. But what exactly is a CMDB?
What is a CMDB?
A CMDB 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 is clear: 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 was developed on behalf of the British government. This work, called ITIL for short, 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 individual components of a CMDB are stored in Configuration Items (CIs). However, the term “configuration” is a little misleading in this context, since these are not concrete configurations of real devices. Rather, the term in this context stands for the representation of the mutual dependencies of the stored objects.
From the perspective of the CMDB, a Configuration Item (CI) is an object, first of all. This object can be a server, a building or even a person. Various properties can be assigned to these CIs.
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.
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.
IT documentation and CMDB – are there differences?
The biggest difference between CMDB and IT documentation 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
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 to build a really working CMDB
CMDB projects cannot be completed “just like that”. And because they are so demanding, many myths and legends surround these projects.
In this white paper, we bust the biggest myths about CMDB projects in 8 chapters. Here you will find valuable tips on how you can build a functioning CMDB in your company.
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 as rescue network 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).
Introduction of a CMDB
When implementing a CMDB, consider the different needs of different departments and stakeholders. Get everyone involved early into the project.
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:
The software should make it possible to create a central CMDB from distributed data sources via any interfaces.
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
In a CMDB implementation project, roles and responsibilities should be clear.
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.
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.