Understand IT change management vs. configuration management
When examining change management vs. configuration management, it's easy to confuse them. These examples 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 know how best to implement them. This is crucial 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 these processes are discussed here in the context of ITIL, which is a framework for IT service management (ITSM).
What is change management?
Change management is easier to define than configuration management. IT ops teams constantly battle to keep systems running and manage changes both intended and unintended -- and here 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.
This article is part of
What is configuration management? A comprehensive guide
To see what change management in IT looks like, consider these examples:
- A standard change may include system patches. Consumers and administrators of a system need to know that patching has occurred to be aware of potential complications, but typical patching may not need to go through rigorous testing. An emergency change example would be an out-of-band patch to address a vulnerability.
- Unplanned changes often occur when an administrator addresses a problem, such as to reboot a failed server. These actions do not go through the usual change management process, and details might be recorded only after the fact.
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.
To see where configuration management provides real-world benefits, consider these examples:
- When a service fails, an IT team often consults a map of configuration items to understand the effects. For example, if a server hosts a database containing many different applications and the server needs to be rebooted, mapping the applications to the database and server can quickly assist you in notifying the application owners of an outage.
- Code as a configuration is a commonly used IT technique to verify that code is documented, reproducible and managed. Managing the configurations of a given service using code allows a team to quickly spin up an environment for test or development purposes.
Differences between change management vs. configuration management
While the two areas intertwine, there are stark differences between change and configuration management.
Change management is the process to track and identify changes that occur within an environment. This generally involves how to ensure only authorized modifications are made to an item while mitigating risk and impact. Configuration management, on the other hand, deals with how to identify, record and verify the configuration items and their inter-relationships.
Configuration management supports change management through identification of the assets and systems that might be involved in a change, but it will not track a given change itself. Nor will it manage the risks and the effects associated with that change.
Where change management and configuration management overlap
To truly understand how a change affects any given system, you need configuration management. With all the configuration items and their dependencies mapped, it's easier to decipher which systems and components a change has affected.
Not all configuration items are systems. Documentation can be a form of configuration item. When a change goes wrong, you'll want to know who is the process owner and which documentation needs an update.
In this way, information within a configuration item directly influences how IT teams implement a change.
Consider these typical examples of where change management and configuration management overlap:
- A team deploys a configuration change to a production environment. This process must adhere to the change management process of approvals and reviews, and only then is the configuration update to code deployed out to a production system, and proper notifications sent out.
- A database migration from one server to another includes change management of the analysis, notifications and approvals. This also requires updates to the CMDB and any configurations that may affect consumers of the service.
Examples of using change and configuration management in IT operations
The below examples further illustrate how change management and configuration management complement each other as well as how they differ.
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 are not being received. The obvious answer is to blame the new release, but where exactly does the problem lie?
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. It seems reasonable to assume that an update to this configuration file is also necessary to support TLS 1.2.
Subsequently, updating this file to use the correct TLS version fixes the issue and all queued emails will send. 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. A proper restart of the system involves a defined order and a specific series of steps, so it's important that the process is well-defined and followed.
After the previous monthly restart, IT makes additional changes to support a new subsystem. In the following monthly restart, several systems do not boot up correctly, even though admins followed the new process correctly. Referencing CMDB documentation, IT contacts both the process owner and the individual who last updated the procedure. Investigation might find that the change for the new subsystem 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 subsystem 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.
