Configuration Item (CI)
Definition of Configuration Item (CI)
Configuration Item (CI) A Configuration Item is an entity in a configuration management solution such as a CMDB. ITIL defines a CI as any component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.
The term "configuration item" can be applied to anything designated for the application of the elements of configuration management and treated as a single entity in the configuration-management system. Configuration items, their versions, and their changes form the basis of any configuration audit. The entity must be uniquely identified so that it can be distinguished from all other configuration items. From the perspective of the implementer of a change, the CI is the "what" of the change. Altering a specific baseline version of a configuration item creates a new version of the same configuration item, itself a baseline. In examining the effect of a change, two of the questions that must be asked are:
- What configuration items are affected?
- How have the configuration items been affected?
- The use of the CI within a product can be traced in a robust status-accounting system.
- The CI is subject to acceptance verification based on established criteria.
A configuration item can not only be at the most atomic level, but also can consist of a more complex assembly of other configuration items. In other words, a configuration item can be a primitive component or an aggregate of other configuration items. In fact, the level at which a configuration item is considered as primitive or aggregate is often decided by the system in which it is created, maintained and managed. With the help of processes and tools, configuration management looks after the configuration items, especially with regards to change management, status accounting, identification and any audits. Common configuration types include software, hardware, communications, location and documentation. Configuration items have specific attributes as well as relationships that are often unique for configuration items underneath them in the particular system. Configuration items help in identifying the components of a system. In configuration management it helps in tracking the granular changes and helps in system maintenance as well for any possible error detection.
Types Of Configuration Items (CIs) in ITIL
- Service Lifecycle CI: This type of CIs includes the information about services and answers the questions on:
- How will the services be delivered?
- When will the Service be realized?
- Expected benefits?
- Cost of Service.
- Service CI: Service CIs includes,
- Organization CI: Organization CIs are internal to an organization and mainly refers to the internal documents. For e.g.-Business strategy, policy etc.
- Internal CI: Represents CIs which are delivered by individual projects, including tangible & intangible assets.
- External CI: External CIs refer to external customer requirements and agreements, releases from supplier and external services.
- Interface CI: Interface CIs are required to deliver end-to-end service across a Service Provider Interface (SPI). For example, escalation matrix and documented process of transferring incidents in-between them.
Characteristics of Configuration Items (CI)
A configuration item (CI) is any service component, infrastructure element, or other item that needs to be managed in order to ensure the successful delivery of services. Each CI has several characteristics:
- A classification, or type, which indicates what kind of item it is.
- Attributes, which vary by classification and describe the characteristics of the individual CI.
- A status value, which represents the CI's state in the lifecycle used for CIs of this classification.
- Relationships, which indicate how the CI is related to other CIs.
- An owner, the person who is responsible for the CI.
CIs vary in complexity, size, and type. They can range from an entire service, which may consist of hardware, software, and documentation, to a single program module or a minor hardware component. The lowest-level CI is usually the smallest unit that will be changed independently of other components.
Actual and Authorized CIs
An actual CI represents an item in the environment; its attributes reflect its condition as determined by the discovery process. An authorized CI is a representation of a corresponding actual CI, reflecting only the attributes that you want to manage through the change management and configuration management processes. You can create authorized CIs from actual CIs using the promotion process. You can also create authorized CIs that do not correspond to actual CIs. For example, you might have a CI that represents a service or other logical object that would not be discovered. Authorized CIs can be chosen as targets of a change request or other process. You can run audits, or reconciliation reports, to check on the differences between actual and authorized versions of configuration items, and then take corrective actions as needed.
The classifications, or types, of actual configuration items are defined in the Common Data Model. This model defines the types of CIs along with their attributes and relationships. You cannot create, change, or delete the CI types that are defined in the Common Data Model. However, you can create your own classifications for authorized configuration items, and you can determine which types of CIs you want to manage using the configuration management and change management processes. This determination is an important part of planning for effective use of these processes.
Top-level Configuration Items
A top-level configuration item is a CI used as the starting point for organizing and promoting a set of related configuration items. An example of a top-level CI is a computer system. It can have many child CIs, such as an operating system, application software, and hardware components. When viewing a list of CIs in the Configuration Items or Actual Configuration Items application, you can see which ones are top-level CIs by checking the Top-level column. Knowing which CIs are top-level is important because when you create authorized CIs by promoting actual CIs, you must choose actual CIs that correspond to the top-level authorized CIs for which you have defined promotion templates.
Examples of Configuration Items
All configuration items (CIs) are uniquely identified by CI registration codes and version numbers. A CI may be a primitive system building block (e.g. code module) or an aggregate of other CIs (e.g. a sub-system is an aggregate of software units).
The figure above depicts the configuration of an underground railway environmental control system. The system has a central operation control centre and many railway stations. Each station has:
- A local control processor (LCP) that allows operators to display and manipulate the air conditioning system and smoke extraction fans
- A remote terminal unit (RTU) that performs the control function and
- An integrated backup panel (IBP) that allows operators to take over manual control of the system.
For the purposes of example let's look at the configuration items identified for the remote terminal unit control software. The RTU has three components that are managed as self-contained units for the purposes of identification and change control:
- The firmware - the operating system that runs the remote terminal unit
- The configuration - this is a data file that determines the operation of the RTU
- The logic - the application software that performs direct digital control functions.
These three components were identified as primitive level configuration items as they cannot be further decomposed and are managed as self-contained units. For example each logic file that is loaded into the RTU has a unique identifier and version number. The RTU is an example of an aggregate configuration item. An RTU CI release is an aggregate of firmware, configuration and logic CIs. The station CI is another aggregate configuration item. A station CI release is an aggregate of the individual LCP, RTU and IBP CI releases.
Designating Configuration Items
The choice of aggregate and primitive level configuration items is driven by the way the development, operation and maintenance of a system is managed. For example the station CI was selected as a configuration control item because it is useful to have one revision identifier that indicates the configuration status of all control system components at that location. The revision level assigned to the station CI denotes the level of functionality available and the possible modes of communication with the operation control centre. General guidelines for identifying configuration items are:
- CIs are released as a unit to the customer
- Example: Mission computer, accounting package
- CIs may be replaced as a unit in the field
- Example: Modem, Remote Terminal Unit (RTU)
- CIs perform a meaningful stand-alone function
- Example: RTU
Configuration Management (CM)
Configuration Management Database (CMDB)
Configuration Lifecycle Management (CLM)
Product Lifecycle Management
Enterprise Resource Planning (ERP)
Software Development Life Cycle (SDLC)
- Configuration Identification MIL-HDBK
- Connecting the Concepts: From Configuration Item to Release Policy Pierre Bernard
- 11 Examples of Configuration Items Simplicable
- Configuration items in an ITIL CMDB BMC
- Can a Document Be a CI (Configuration Item)?https://www.cmpic.com/configuration-management-configuration-item.htm Steve Easterbrook]