Planning what data to store in the CMDB

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

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 

Relationships among CIs in a CMDB

Configuration items (CIs) do not exist in a vacuum; they affect each other. For example, one CI could use, depend on, be a component of, enable, be a member of, or be located in another CI. Storing these relationships in the CMDB enables you to see how CIs interrelate and affect one another.

Relationships can be simple, such as a disk drive being a component of a computer system, or more complex, like those shown in the following figure:

 Example relationships 

Relationships exist not only between physical CIs, but also between logical and conceptual CIs, such as the software instances and service instance in the following figure. Two CIs can have more than one relationship with each other: for example, an employee might own a server and also operate it.

Relationship data makes the CMDB a powerful decision support tool. Understanding the dependencies and other relationships among your CIs can tell you how upgrading Processor A would improve Server B's performance or which services would be affected if Router C failed. Most downtime is caused by problems stemming from configuration.

Data related to CIs

You might have information related to configuration items (CIs), such as incident tickets, change events, contracts, service level agreements (SLAs), a Definitive Media Library (DML), and so on. Though these things are not CIs themselves, they contain information about your CIs and are an important part of your IT infrastructure.

You can federate related data to make it available through BMC CMDB. For more information about federating data, see Planning to use federated data.