The ITIL 4 change control practice

The purpose of the change control practice is to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.

When business services are running on a cloud such as AWS, Azure, or Google, it refers to the change control of the individual cloud services used to run an application and provide a service – not the cloud service provider (CSP) as a whole.

Changes are managed in one of three ways:

  1. Standard, low-risk changes with no management required
  2. Normal changes that require normal change management
  3. Emergency changes outside the change schedule.

The good news for IT service managers who are using ITIL 4 with cloud is that changes are more automated, and more services are off-loaded to the cloud. And, therefore, the burden of change management should be reduced. However, the process can remain the same.

How change control works in the cloud

Despite the snarky comments such as: “Cloud is just someone else’s server,” the reality of cloud is that it’s an opportunity to reduce the operational burden through automation and off-loading.

For example, by automating changes using advanced services such as AWS EC2 Autoscaling, changes for capacity require no change process. And by offloading management from “roll your own databases” to higher-order managed services like AWS Relational Database System (RDS), the majority of the effort such as patching and changes are performed by the CSP.

Cloud reduces the burden on change control (or change management) practices in a number of ways including:

  1. How changes are performed is the CSP’s decision, but when changes are performed – the change window – can be agreed.
  2. The scope of changes is reduced to the nobs-and-dials configurations exposed by the CSP to the cloud administrator, which leads to more standard changes.
  3. Automation means some changes can be dropped from the change practice/process entirely.
  4. Using high-order services (where more of the delivery is done by the CSP) means a large number of changes can be dropped from the change practice/process.
  5. Using the CSP’s native ITSM tools for applying, tracking, and auditing changes.

As in all things cloud, the key to success is adjusting your organizations thinking – for instance, how to apply ITIL 4 – to exploit cloud characteristics. This means avoiding the application of non-cloud practices to cloud.

As an example, cloud services such as AWS EC2, S3, and RDS are all completely decoupled. This means discrete, per-service changes can be applied without impacting other services. This leads to a “frequent, small, standard changes” mindset as opposed to the familiar, non-cloud mindset of “infrequent, large, normal changes.”

Cloud dos and don’ts for change control

To exploit the cloud’s programmability, automation, and services to improve your change control practices, please consider the following dos and don’ts:

Do:

  • Change implementation should be applied programmatically which helps with change documentation. Avoid “clicking in the UI or web console.” This can be as simple as a one-line command or a complex release pipeline.
  • Changes should be logged in an immutable log like AWS Cloudtrail.
  • Changes should be alerted with monitoring services like AWS Config.
  • It’s important that the principle of least privilege is applied to cloud such that an S3 service administrator can only change S3 and not EC2.
  • It’s a cloud best practice to separate out different functions into different cloud accounts to limit the impact of a change failure. For example, only letting developers make changes to development means they’ve less chance of accidentally changing production.

Don’t:

  • Avoid change management in the cloud. It’s common for cloud to be initially adopted by developers who think DevOps is all that’s required and don’t consider ITSM needs. ITSM practitioners must be involved in cloud.
  • Let people make untracked changes to the cloud. It doesn’t take long for cloud accounts to become an unruly mess that requires painful remediation.
  • Take the easy route of implementing changes by “just clicking that checkbox.” Using version control and programmatic change control might feel harder and “not needed…yet” but it’s what will save you when it all goes wrong.

Applying your organization’s ITIL 4 change control practices to your organization’s use of the cloud should be a successful experience but it requires a shift in thinking and application.

The cloud is highly programmable and instantly changeable – which can be a good or bad thing. The cloud is also full of useful change control (or change management) tools which are often free to start with. So, get acquainted with them and use them as early as possible.