Home �   ITIL�  Index

Leveraging Configuration Management

Mar 23, 2005

George Spafford

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.


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.

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.