Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How change management and configuration management differ in IT

When examining change management vs. configuration management, it's easy to confuse them. The examples below illustrate how they intertwine, but still address different areas.

IT is rife with exorbitant -- and often conflicting -- processes that IT admins must carry out with speed, efficiency and success. These admins must understand the differences between certain IT processes, as well as how they overlap, to design, grow and manage an effective IT organization.

Different organizations have different definitions of change management and configuration management in IT. In an effort to establish a baseline understanding, both processes are discussed here in the context of the IT Infrastructure Library (ITIL) framework for IT service management (ITSM).

What is change management?

Change management is easier to define than configuration management. The constant battle to keep systems running and manage intended -- and unintended -- changes is where change management excels.

Broadly speaking, change management is a set of standardized methods and procedures that minimize the effect of change-related incidents within the IT organization. It's the process by which IT admins -- or software -- track and identify changes that occur within an environment. This process generally ensures that only authorized modifications are made to an item to mitigate risks. Change always brings the possibility for system errors or service issues -- so, change management enforces that all modifications are well-planned and executed.

What is configuration management?

Configuration management is a bit more difficult to define. Originally introduced in ITIL 2, configuration management was renamed in ITIL 3 to Service Asset and Configuration Management. Regardless of the name change, the idea is equivalent.

ITIL defines three general components of configuration management:

  • Configuration model. The model specifies the types of configuration items that are represented, which attributes are tracked and how those items are related.
  • Configuration items. An individual unit within the configuration model with associated attributes and relations.
  • Configuration management system. The set of tools used to store, manage and analyze the data of configuration items and their relationships. This is often referred to as a configuration management database (CMDB).

Combined, these three concepts outline the goal of configuration management: to identify, record and verify the items inherent in any IT system -- not just the physical devices -- and the relationships between them.

ITIL sees another update

The ITIL framework was revamped again in 2019 with the launch of ITIL 4, which differs in several ways from previous versions.

Differentiate change vs. configuration management

Change and configuration management easily intertwine, and while there are areas of overlap, they address two entirely different areas.

For example, although configuration management supports change management through identification of the assets and systems that might be involved in a change, it will not track a given change itself, or manage the risk and effects associated with that change.

Overlaps between change management and configuration management

IT admins can only truly understand how a change affects any given system with configuration management. With all the configuration items and their dependencies mapped, it's easier to decipher the systems and components a change has affected.

Not all configuration items are systems, either. Documentation can be a form of configuration item. Therefore, track and understand a change to a process -- or process ownership -- to better identify when a change goes wrong and where documentation needs an update.

In this way, information within a configuration item directly influences how IT teams implement a change.

Change and configuration management examples

The below examples further illustrate the difference between change management and configuration management -- and how the two processes intersect.

Software update gone awry

A new software update is released into production to migrate to TLS 1.2; soon after, customers complain that emails sent through the application aren't being received. The obvious answer is that the change caused the issue, but what isn't obvious is where exactly the problem lies.

The CMDB tells IT admins that the application in question relies on a secondary service to send emails. According to the configuration item, this service has a configuration file. Looking back at the committed change, it doesn't mention an update to this configuration file. Due to the scope of the change, it is reasonable to assume that an update to this configuration file is also necessary to support TLS 1.2.

Subsequently, the IT team updates this file to use the correct TLS version, which fixes the issue and sends all queued emails. The CMDB contained all related dependencies and enabled IT admins to inspect the change request to determine whether the deployment process was correctly followed.

Monthly update process failure

A crucial accounting system undergoes monthly restarts to apply updates and ensure the system runs smoothly. IT admins use a CMDB to track the process documentation they must follow to restart the system. Because there is a defined order and a specific series of steps that dictate how to restart the system properly, it's important that the process is well-defined -- and followed.

After the last monthly restart, IT made additional changes to support a new sub-system. In the following monthly restart, several systems do not boot up correctly, despite admins following the new process correctly. Referencing CMDB documentation, IT contacts both the process owner and the individual who last updated the procedure. After additional investigation, the admins find that the change for the new sub-system did not take into account the existing systems that need extra time to restart.

The IT operations team adds in extra wait time to enable all other systems to restart before the new sub-system restarts, which completes the process successfully. In this example, maintaining the process documentation and attributes -- such as ownership -- in the CMDB enabled a quick resolution to the issue.

Dig Deeper on Configuration Management and DevOps

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

SearchSoftwareQuality

SearchAppArchitecture

SearchCloudComputing

SearchAWS

TheServerSide.com

SearchDataCenter

SearchServerVirtualization

Close