Should each software version be a separate CI –or- should it be an attribute of the CI
By ITIL® from Experience ©
It is tempting to treat the version of software as an attribute of the Configuration Item (CI). After all most discovery tools can identify the version of a product which can be imported in the Configuration Management Database (CMDB) as an attribute of discovered CIs (see Should we automatically import auto-discovered CIs in the CMDB). Moreover, this aligns with ITIL® version 2’s guidance1 and works well for hardware CIs2 .
However, this approach is a challenge with software (i.e. operating systems or applications). When software is upgraded using a phased approach the Service Desk will receive calls on both the new and the old version until the release/deployment is complete and that the previous version is completely retired. Thus, one CI is required for each version to properly log incidents or service requests, to manage them and to generate accurate reports. In addition, historical information may be required on a specific version which would not be readily available if only one CI is used and its version attribute is changed from one version to the next.
Fortunately, ITIL® v3 addresses this challenge. It mentions that “individual CIs should be uniquely identifiable by means of a unique identifier and version.”3 4 Furthermore, it mentions that “The identification should also differentiate between successive versions and should enable the items under control to be unambiguously traceable to their specifications or to equivalent documented descriptions.”3
To confirm that using one CI per version of a software is the correct approach let’s briefly review if it meets some of the ITIL® processes’ needs. After all, the raison d’être of the CMDB and Configuration Management is to enable ITIL® processes.
Problem management needs one CI for each version of software so that it can record a problem against the right version for trend analysis and to properly classify known errors accordingly. Two CIs also enables Problem Management to archive problems in the Known Error Database when a version is retired (see How to ensure that applications and servers are decommissioned).
From an application management perspective, the development group works with a newer a version to prepare a release. As such, two CIs should be used, one for each version, so that the CMDB can accurately reflect the configuration of the live and development environments to enable Change Management to adequately manage these environments.
For IT Asset Management (ITAM)5 , one configuration item per version is required to enable it to manage software licenses and compliance.
As we have seen, software versions should be represented by separate CIs. That being said, a similar thought process can be used to determine if patches should be treated as separate CIs or recorded as an attribute. To conclude, “Choosing the right CI level is a matter of achieving a balance between information availability, the right level of control, and the resources and effort needed to support it.”6
Published on: 2013-01-13
Last updated on: 2017-09-09
"Don't start by defining the CI. First, figure out your process, then identify the data, CIs and attributes required to enable it."
- Why asking what you want to report on is the wrong way to implement a tool
- Which CIs to load first in the CMDB
- Who is responsible for the CI relationships
- Why is the CMDB inaccurate
- How many Configuration Librarian(s) do we need
ITIL Process > Configuration Management
Copyright 2013 - 2017 ITIL® from Experience - D.Matte