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.

Configuration Management

The challenge is to have as few CIs as possible to achieve the goals of the business. The mantra shouldn’t be to zealously reduce CIs and cripple the business — that is clearly not the message. The intent should be to balance the need of new requirements against the existing defined CIs and try to provision the solution using existing approved CIs.

Configuration Management, a key domain of ITIL that is covered in the Service Support book, is concerned with the tracking of all configuration items in use by the organization and controlling the introduction of new CIs into the Configuration Management Database (CMDB) as well as the controlled removal of obsolete CIs.

Configuration Management is akin to inventory management. The configuration management group, dedicated or at least tasked with the responsibilities, must know what exists, track status and audit configurations in production to their known baselines to ensure that all CIs in production are also being tracked in the CMDB. Savvy IT groups will also use this baseline-to-production comparison to flag unauthorized changes and strengthen both their operational processes and overall security.

Benefits

Readers may be wondering about the value of tracking all of this data. The answer is that in order for the Release Management team to provision systems and normalize the builds to reduce variation, you must first know what you have. The same for Problem Management teams — they must know what they are dealing with and so on.

For small shops, this may sound ridiculously easy. Yet, for large shops with more than a thousand servers, this is suddenly very daunting and expensive, but there are very significant benefits to take into consideration:

• Volume purchasing becomes possible. To illustrate, economies of scale make it cheaper to buy 100 identical servers than 100 unique servers.
• Through the use of repeatable build tools, such as Ghost, IT can create one baseline build and then automatically propagate it to the other identical systems far faster than doing multiple unique builds.
• Patching becomes far easier as IT can afford to spend more time thoroughly testing a patch on a few builds vs. many unique builds.
• People build up expertise vs. general knowledge. Instead of needing to understand the nuances of Sun, HP and IBM UNIX servers, imagine if engineering and operations can focus on just one hardware platform and just one version of UNIX.
• As expertise increases, the Mean Time To Repair (MTTR) will decrease. It is far more likely that IT ops will be able to solve a problem if they have deep knowledge about a platform vs. very thin knowledge about many platforms.
• Processes and procedures are easier to develop and maintain with fewer variations. Environmental complexity can make for a challenging documentation problem.
• As variation decreases and knowledge increases, even if the organization lacks formal mature processes, security improves. Ideally, organizations are learning about the benefits of process maturity and documented standardized policies and procedures. If they leverage reduced variation and a push towards process maturity, the benefits skyrocket.

Summary

IT needs to ensure that they have effective configuration management controls and are working to maintain an accurate inventory, normalize the CIs in use and reduce variation. The goal isn’t to stop change and advancement. The objective is to simply control the rate of growth of new CIs. Organizations that embark on this journey will see many substantive benefits including cost reductions and improved service levels.