What is a CMDB?

It is a file, a database where technical information of information systems is stored, such as the list of servers, databases, different applications and software packages, but also business elements such as processes or contracts. In the lexicon of a CMDB, all these elements are called "Configuration Items" (CI). 💡 A properly populated CMDB allows for better planning of the ISD strategy, steering, and associated project management.

Concretely, what does it bring me?

Blog image

Before going into details, here are some use cases of a CMDB:

Perform an impact analysis: When it is necessary to carry out an update or deployment operation on a batch of servers, the CMDB can help identify the applications or services that will be impacted and warn the associated application managers.
Define the scope of a penetration test (Pentest): A penetration test will be all the more relevant if all IT assets exposed to an attack are well within the scope of a penetration test or a vulnerability audit.
Provide proof of IS compliance: The CMDB provides documented evidence of compliance with necessary processes and regulations (ISO27001, SOC2). This can be particularly useful during internal or external audits, or other management processes, particularly for statutory auditors.

But what else?

Implementing a CMDB in your organization offers many other advantages:

Integration with ITSM: In the context of good monitoring of information system operations, being able to link incidents and information system elements is key. However, the service desk must be rigorous in qualifying each ticket.

This is one of the main reasons for the presence of an integrated CMDB in ITSM (ticketing) tools.

An overview of the IS: With detailed and complete information provided by a CMDB, IT service managers can make better-informed decisions. Whether determining an application's lifecycle, planning an upgrade, understanding the impact of an outage, or listing licenses for a software audit, a CMDB helps in effective decision-making.

I don't believe there are good or bad CMDBs...

❌ False! A good, robust, effective, and operational CMDB must follow these 3 commandments:

It contains comprehensive information: A good CMDB is a vast data repository containing detailed and up-to-date information on each CI, including its current state, historical data, associated documentation, and details on each interaction within the system.
It keeps information on relationships: A CMDB doesn't just store information, but also integrates the complexity of relationships and interfaces that make up the company. This relationship mapping can provide valuable insights for understanding the potential impact of a change on interdependent services.
It supports other ITSM processes: A successful CMDB is not standalone; it supports other ITSM processes. This includes incident management, problem management, and change management, providing the baseline data these processes need to operate effectively.

But tell me Jamy, who is responsible for its content?

Blog image

The CMDB serves as a central point for IS documentation. Several ISD professions are therefore involved in its maintenance.

The CIO or IS Manager: Uses the CMDB to get an overview of the information system, facilitating strategic and operational decisions. Also uses it to identify and manage risks (Risk management) associated with changes in IT services.
The Operations or Support Team: This team is the main interested party in incident, problem, and change management. A strong link often exists between the ticketing tool and the CMDB to identify which IS element an incident or change project relates to. This team can also use the CMDB to perform an impact analysis during a change or maintenance.
The Architect: Is in charge of guaranteeing the accuracy of the CMDB and keeping it up to date. Their work has significant influence on all processes and decisions that rely on the CMDB.

Does it seem too good... to be true?

It seems obvious that a CMDB brings a lot of value to its users. Yet not all companies have a CMDB, but why?

Lack of automation: Historically, CMDBs were filled manually and are still mostly so today. Some solutions offer automatic discovery but the effort of building and maintaining a CMDB remains very substantial, especially in ISDs that cannot afford to dedicate an architect to the subject.
Technicality: Without being a field of expertise in itself, the lexicon linked to a CMDB is not simple and the relationships between different elements (the famous CIs) can be complex. Access to information is not obvious and it is difficult to imagine that a project manager can contribute to a CMDB. Adding management software - often a software package or open source software - also implies maintaining it and calling on external consultants.
Lack of agility: The CMDB documentation process conflicts with self-documentation mechanisms used in implementing Agile methods and infrastructure. For example, infrastructure-as-code (IaC) represents in itself a form of documentation that will duplicate the CMDB.

Continuous deployment implies regular changes in an application's architecture and the CMDB will struggle to track modifications.

Absence of long-term vision management: Best practices for configuration management apply to documenting the existing but there is little temporal vision of the information system that would allow constituting an ISD roadmap or an IS master plan (SDSI).

The battle: CMDB vs ...

There are indeed alternatives to CMDBs, either in other areas (Finance) or with higher-level objectives (Enterprise Architecture).

🥊 ITAM

IT Asset Management (ITAM) and CMDB are often confused, but they are distinct. ITAM focuses on managing an organization's IT assets throughout their lifecycle from a financial perspective. Meanwhile, CMDB focuses on IT infrastructure and its associated components and their relationships, providing a holistic view necessary for effective IT management.

🥊 Enterprise Architecture (EAM)

Enterprise Asset Management (EAM) is a broader concept that encompasses all assets of an entire organization while focusing on maximizing service delivery and asset lifespan. On the other hand, a CMDB is specifically adapted to meet ITSM needs, offering detailed interactive views of IT infrastructure assets and their relationships in the context of ITSM.

In conclusion, today I learned

→ The decision to implement a CMDB should be based on a solid understanding of what it can offer and its alignment with an organization's goals.

→ Even with challenges, a carefully implemented and maintained CMDB can enhance ITSM by improving decisions, optimizing processes, and reducing risks.