Do I really Need an ITIL CMDB to create my IT documentation? I am often asked this question when working on documentation projects. Before I answer it, I’d first like to explain the basics of an ITIL CMDB and how it is structured. ITIL is short for IT Infrastructure Library and provides a well-known and widely used IT process framework. When using ITIL, it is recommended to introduce a CMDB (Configuration Management Database) or a CMS (Configuration Management System). The problem is that certain basic properties are required, but ITIL does not provide any specific instructions as to how the CMDB is to be structured in detail. At its heart, the CMDB consists of so-called CIs (configuration items). CIs can be related to each other in any desired way. To give you an example: A network adapter (CI 1) is a part of a workstation (CI 2).
Consistent CMDB system required
In a CMDB, it should further be possible to define so-called baselines which are used to reflect a certain configuration state. It should be possible to compare the various baselines with each other. A CMS system groups multiple existing CMDBs to form a consistent system. This alone indicates a basic problem which unfolds in practice: Usually more than one CMDB exists in many companies or there are at least multiple information sources for the CMDB. Since the CMDB essentially forms the foundation for the system documentation and many different products and solutions from various providers are always involved here, it is often not easy to obtain the required data. Currently, many providers offer information retrieval for their own products, but a cross-vendor solution is hardly conceivable. Most inventory software, however, only scans the existing hardware and the installed software. For an effective CMDB, it is also necessary to gather information on configurations and other items such as application servers and their settings.
IT documentation requires accurate data selection
From my experience, I can say that most people under-estimate the complexity of the associated information. As much information as possible should be transferred to the CMDB at the beginning of a project and later to the IT documentation. However, you should keep an eye on the maintenance effort and the information content. Much of the information will only be maintained if automatic data acquisition is possible. Highly detailed data will more often lead to confusion than to solving a problem. For this reason, you should think long and hard about what data you actually need. The CMDB structure must be aligned with the intended use.
To build your IT documentation and, in particular, the system documentation, a well-structured CMDB is of vital importance in my opinion. The process documentation in a company often refers to the CMDB or provides guidelines for editing the CMDB. It is also important to find out how data changes within the CMDB affect the existing IT documentation. Hence it would be best to firstly define processes which ensure that the IT documentation is always up-to-date.
For more on this topic: Professional IT documentation with Docusnap
