Many organizations struggle with defining what should be a configuration item within their Configuration Management Database (CMDB) or Configuration Management System (CMS) when more than one CMDB is utilized.
A configuration item (CI) is defined by ITIL as “any component or other service asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system and is maintained throughout its lifecycle by service assets and configuration management. Configuration items are under control of change management.”
To help explain what a CI is, lets explain the following:
- What are assets?
- CI within CMDB concepts
- Multiple CMDBs within a CMS
- Organization decision support related to CIs
What are assets? Asset or strategic assets are capabilities and resources of the organization. Capabilities can be defined in categories of people, knowledge, process, organization, and management systems. Resources can be in categories of people, information, data, applications, infrastructure, and financial capital. With this in mind a CI can be any IT asset…
But, let’s consider CIs within a CMDB have structure, criteria, and attributes.
- Structure – First a CMDB shows relationships between CIs. For example, an application runs on a particular server, which is on a particular network.
- Criteria – Next the CIs within a CMDB have scope and detail. Scope is a category or type of a CI, such as a personal computer CI, network CI, application CI, or database CI. Detail refers to each scope type (for example, the details of a PC — motherboard, hard drive, etc.).
- Attributes – The details of the CI, such as capacity, vendor, and more.
Structure, criteria, and attributes of a CI are organizational specific depending on maturity and how they manage the assets. If an organization manages the changes to PCs at the PC level vs. at the component level of each PC, then within the CMDB for PC detail there should not be related CIs, such as mother board. For this CI only the PC CI is needed with an attribute related to the PC that can include motherboard info if it is needed for decision support.
Each CI within the CMDB should be designed from a scope and detail perspective and be unique, all while including the requirements to deliver a service, if it’s under change control, and if it’s manageable by the organization. Assets that are not managed by the organization, and are not under change control, but still can be articulated in the CMDB as attributes of CIs that are managed by the organization.
When using multiple CMDBs within a CMS, it is suggested that one CMDB becomes the master or single source of truth. This is done using CMDB reconciliation to the master CMDB.
Organizations should remember CIs in the CMDB should not be thought of as just a technical endeavor, but as a business endeavor to help with decision support. Organizations should be careful of over doing the CIs with a CMDB to avoid complexity for no value. Too many levels of detail related to CIs can affect overall business performance and have diminishing returns. Knowledge management is an important process to help with decisions related to CIs for decision support and overall building of a Service Knowledge Management System (SKMS) for the organization.