A configuration item (CI) is a component of the Information Technology Infrastructure Library's (ITIL®) method for change management. It is the smallest principal component of the configuration management system (CMS), which is stored and tracked within what's known as the configuration management database (CMDB). The collection of configuration items in the database is used by an information technology (IT) manager to track relationships with other items and monitor an IT project or service's life cycle. Configuration items may be anything identified in the IT service as needing management tracking, including computer hardware, software, protocols and processes.
Upon being identified and entered into a CMDB, the configuration item becomes a configuration record. The record details the parameters of the CI, as well as its relationship with other CIs. As virtually anything can be a CI, there can be a bit of confusion with regards to the potential granularity. Configuration items can be higher-level concepts, such as a process description that needs to be managed for changes over time. As part of that process, however, sub-components such as the computers or people who implement the process may further be identified as CIs.
This tiered structure typically finds configuration item records in a number of databases, perhaps even managed by different levels in an IT service offering. A help desk service, for example, with a process for on-site hardware replacement will have that process entered into the help desk's CMDB as a configuration item. The hardware items for replacement, such as a hard disk, are also stored in the CMDB as CIs, along with the personnel who move throughout the organization and enact the physical replacement. In this scenario, the highest-tier CI is the help desk, where beneath it is the hardware replacement process, then another tier for the hardware, and so forth.
Identification of configuration items varies greatly depending on a myriad of factors. Typically, most of the components pertaining to a project's start-up are included, but as the project lifecycle progresses, changes may be necessary. Recognition of new CIs for the system are evaluated for necessity and their interrelationships, while older CIs receive periodic audits to ensure their continued validity. In this way, the CMDB is kept clean of unnecessary records, and further requirements analysis can occur based on accurate data.