Leveraging Configuration Management

Information Technology (IT) staffs are very concerned about efficiency these days. Interestingly, the topic of configuration items (CIs) from the Information Technology Infrastructure Library (ITIL) isn't discussed very often. This article will discuss what CIs are and the importance of their management.

Unless care is taken in an IT organization, the rate of change can easily be exceeded by the rate of complexity. IT groups must take care that as they react to changes in their environment, they do not create uncontrolled variation.

It is one thing to say, "Let's toss in a new server to host that database." It's an entirely different perspective to say, "Let's ensure that the database software selected is one of our standards and that we can host it on one of our approved platforms." The first does not ensure that variation is managed, while the latter attempts to ensure that standards are followed and variation is controlled.

All things being equal, let's assume that both approaches work and the hosting platform is provisioned and enters production. Under an uncontrolled approach, there could be new hardware, operating system and database issues that are all unknowns and may include latent errors.

In the controlled approach, since the needed server is built upon known standards, there is less variation introduced and certainly fewer unknown variables. It is this methodical identification, testing and reuse that we must achieve.

So What is a CI?

Each CI is akin to each item in a manufacturing bill of material (BOM) that is assembled to create an item. The CI can include hardware, software and documentation. Furthermore, a CI can be comprised of one item (MS Word 2003, for example) or of many in a hierarchical fashion (see graphic at bottom of page).

For each of the uniquely identified configuration items, there is underlying information discussing its attributes. The Service Support book of ITIL provides a basic list of CI attributes to consider in Annex 7C. These attributes are key characteristics that you need to efficiently troubleshoot, replace, upgrade and so on. To illustrate, possible attributes for consideration include:

• Unique key -- The CI Number
• The CI's Name
• Description
• Who owns the CI in IT
• Items the CI depends on
• Items that depend on the CI
• Disaster Recovery Plan
• Audit plan and tools to use
• Change history
• Problem history
• Known errors
• Manufacturer or Vendor
• Model #
• Serial #
• Warranty Information
• Maintenance Window

One question often asked is, "How detailed do I go?" The answer is to go as deep with your CIs as is both manageable and valuable.

For example, drilling down and assigning a CI to every single device driver may be extremely resource-consuming with very little benefit. Pick the level of detail that will benefit your organization the most. For example, maybe the RAID controller device driver is very critical and must have a CI, or perhaps a CI is just assigned to the overall server configuration. Take into consideration the data needed for software licensing, vendor negotiations, service level agreements, security, auditing, etc.