This documentation applies to the 8.1 version of BMC Atrium Core, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Configuration items in an ITIL CMDB

Configuration items (CIs) are the focal point of a CMDB. Without a clear definition of what qualifies as a CI, you will constantly struggle with deciding whether to put certain kinds of data into the CMDB. Simply put, a CI is an instance of an entity that is part of your environment and has configurable attributes specific to that instance. These entities can be physical (such as a computer system), logical (such as an installed instance of a software program), or conceptual (such as a business service). But they must be a direct part of your environment, rather than information about such a part.

The following sections provide guidelines for determining CIs and examples of CIs.

Examples of CIs and non-CIs

The following table gives some examples to illustrate this boundary:

Example CIs and non-CIs

Configuration items

Not configuration items

  • A business service is part of your environment and has configurable attributes, such as criticality to the business and cost of interruption of service.
  • A computer system is part of your environment and has configurable attributes, such as serial number, processor speed, and IP address.
  • A building is part of your environment and has configurable attributes, such as number of rooms, climate control system, and alarm system.
  • An employee is part of your environment and has configurable attributes, such as skills, hours, and department.
  • A software instance installed on a computer system is part of your environment and has configurable attributes, such as license key, patch level, and licenses available.
  • An incident ticket has configurable attributes but is not a direct part of your environment. It is information about other entities (a computer system, for example) that are part of your environment.
  • A software package is not part of your environment — only installed instances of it are — and is usually stored in the Definitive Media Library (DML).
  • An event does not have configurable attributes and is not part of your environment.

Of course, not everything that qualifies as a CI is worth tracking. For example, you probably will not create records in the CMDB for all the office chairs in your organization.

CI eligibility matrix

Consider creating a CI eligibility matrix to help you make decisions about which items in your IT environment should be CIs. A CI eligibility matrix lists each CI candidate, its CI type (such as infrastructure or service), and several eligibility criteria to consider as part of your decision-making for CI candidates. Specific eligibility criteria vary according to the needs of your business, but consider using some of the following criteria:

  • Cost or value — Does the CI candidate have an associated monetary cost or value to your business?
  • Change considerations — Would the CI candidate be impacted by IT change requests?
  • Traceability — Are you required to track changes made to the CI candidate?
  • Governance and compliance requirements — Is the CI candidate crucial to maintaining compliance with standards and other requirements?
  • Management of service commitments — Is the CI candidate required to help you meet your service commitments to the business?
  • Maintainability — Are you required to maintain the CI candidate?
  • Delivery cost and quality — Is there a monetary cost associated with how the CI is delivered and maintained?
  • Do you, and not a third party, manage the CI candidate?
  • Is the CI candidate unique?
  • Other factors specific to your business needs.

Use the individual eligibility criteria to set your overall acceptance criteria. For example, you might determine that if a CI candidate meets a simple majority of your eligibility criteria, it should be a CI. You might determine that a candidate must meet each of a select few eligibility criteria to qualify as a CI. You might determine that one eligibility criterion is more important than the rest. The final decision is rooted in your business needs.

After you have set your overall acceptance criteria for determining how a candidate will be evaluated, assess each CI candidate against each eligibility criterion as yes/no or true/false, with yes or true indicating that the candidate should be a CI. After you assess all criteria for a CI candidate, see your overall acceptance criteria to reach a final decision for that candidate.

Calbro Services use of a CI eligibility matrix

This section shows an example of a CI eligibility matrix for Calbro Services. It shows the eligibility criteria that the CMDB implementation team identified as important for determining whether a CI candidate should be a CI. For each CI candidate, the team reached a final decision based on the following requirements:

  • The CI candidate must meet eligibility criteria D (identifiable) and E (maintainable).
  • The CI candidate must also meet at least one of eligibility criteria A (under change control), B (used for impact modeling), or C (used by the Support team).

After completing the CI eligibility matrix, the Calbro Services CMDB implementation team decided to make CIs for all CI candidates except the Person and Role candidates. Those candidates met the first requirement by meeting both criteria D and E, but they failed the second requirement by not meeting any of criteria A, B, or C.

Calbro Services example CI eligibility matrix

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments