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.
Differentiation between 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
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 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 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).
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
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.
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.