09. 10. 2015
Is a CMDB a Deciding Factor For Service-Oriented Companies?
To keep it short, I could simply answer this question with “Yes”.
Regularly, one of the central requirements of service management projects is the introduction/integration of a CMDB. From my experiences gained from customer projects, I can just confirm this.
What does this mean in terms of practical application?
In this first article, I would like to generally introduce the CMDB topic. In the following article, I will describe the benefits of a CMDB on the basis of practical examples
. In the third article, I will outline the possible realization through the implementation of our IT Service Management solution WÜRTHPHOENIX EriZone.
Let us begin with the consideration of some definitions and explanations deriving from ITIL.
ITIL does not talk about „the CMDB”, it always refers to one or more CMDBs. This corresponds also to praxis. If for example your hardware components are managed in another system than your software licenses are, it will not be necessary to register them in another CMDB. Therefore, a practice-oriented CMDB is more a kind of cloud, which connects the IT systems with each other. The whole builds the required information for all service management processes.
CMDB as a cloud connecting the IT systems with each other
This explains the central function of a CMDB. It is not the primary matter collecting as much as possible technical information in one single database, but of recording in addition to technical data also the relative license, finance and contract data over the entire lifecycle. In concrete, this implies that beside the technical data of a PC or server, also data regarding their software, connections, location, users, contracts (license, maintenance, SLAs …) etc. are collected and stored.
A CMDB should be an instrument for the process of planning, analysis and maintenance. Therefore, it is necessary that the CMDB shows the target state of the configuration items (all service assets, which have to be managed to deliver a service). For example, if a PC is scanned and it is discovered that an HR software and a graphic software are installed, this would be the current state. Although this can be interesting for license management to know if enough licenses are available, it does not provide information about the authorization of these installations. By comparing therefore the target state from the CMDB with the current state, unauthorized changes can be easily determined.
What could be a procedure model for a practice-oriented CMDB?
1.) Definition and identification of the configuration items
First, the objects that are relevant for the service management processes and the required information and relationships have to be identified. Too many or unneeded CIs and attributes rise unnecessary burdens but do not gain any benefit. Here the service catalogue
is a good approach to identify the relevant objects.
2.) Planning and structuring of the CMDB
A CMDB, which is easy to use, manage and maintain, is the basis for a successful implementation. Too complex structures do seldom lead to success. Whereas, the connection and coupling of inventory systems, asset management databases … with the CMDB is essential.
3.) Status monitoring of the configuration item lifecycle
It just make sense to record CIs, which will be maintained afterwards. Otherwise, the CMDB would just be another “data tomb”. This is more an organizational than a technical issue.
4.) Verification of target and current state
As already mentioned above, the verification of target and current state is one of the most important tasks of the configuration management. In this way, high quality can be reached by identifying errors within the service management processes.
Summarizing, it can be mentioned that there does not exist “the CMDB” and neither there is an out-of-the-box solution for all customers. However, a CMDB is one of the central topics and a deciding factor for the success of the implementation of a service management solution.
Latest posts by Martin Fischer