Planning what data to store in the CMDB
ITIL recommends that you store several types of data in the CMDB. Its main purpose is to hold configuration items (CIs) and the relationships between them, which together form a configuration at a particular time or state. ITIL also suggests that the CMDB can hold data related to CIs, such as incident tickets or SLA definitions.
Remember that your CMDB deployment should be based on the needs of consuming applications. Unless and until there is a defined use for a piece of data in your CMDB, ideally that data should not be populated in your 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
Not configuration items
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.
The use of relationships is a critical feature that makes a CMDB a powerful tool, and is a significant difference between a CMDB and an asset store.
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:
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.
When creating relationship instances, you can use the Mapping Your Data to BMC CMDB Classes as a suggested reference for the
Name attribute according to the Relationship Normalization table and also for the source and destination Configuration Items (CI) classes.
The number of relationship classes in the Common Data Model (CDM) is far fewer than the logical types of relationships that you might want to use, so you can achieve a more granular level of categorization by populating the
Name attribute. For example, to specify that a
BMC_Component instance represents a product-to-patch relationship, PRODUCTPATCH is used for the
By using only
Name values that appear in the Relationship Normalization table, you maintain consistency with relationships created by BMC products, increasing the accuracy of reconciliation. Future releases of BMC CMDB will require compliance with the values in this table for compatibility with BMC products.
The Normalization Engine sets relationship
Name values according to the Relationship Normalization table. For more information about this, see Normalization and best practice relationship rules.
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.
Some of these types of data are considered CIs by ITIL.
You can federate related data to make it available through BMC CMDB. For more information about federating data, see Planning to use federated data.