Getty Images/iStockphoto
3 rules to adapt cloud change management policies
Having a change management policy can minimize risk when it comes to making changes. Follow these rules to adapt cloud change management policies and compliance within the cloud.
Most companies develop their basic compliance and change management policies around data center applications. There are new rules to adapt change management and compliance policies to the cloud with the principal focus being software changes.
Compliance ensures conformance to regulatory and internal policies relating to information systems, data storage and use.
Change management ensures that affected parties properly vet changes made to applications and databases so problems can be addressed.
Traditional change management policies link to development processes and, increasingly, to repository-based governance. Software changes at any level and any middleware or OS change would pass through the repository process for development and testing. Then enterprises could apply change management to notify stakeholders who could be affected.
GitOps, a subset of DevOps and an extension of repository-driven compliance, expanded this to deployment. This could alter the application's quality of experience (QoE). It also introduces new tools and APIs that might affect applications. Additionally, enterprises applied the GitOps model to cloud applications, which at the time were primarily IaaS or container based.
Companies started to use public cloud providers' APIs to access new service features, but they often failed to expand their change management policies to incorporate new features. Thus change management failed. Even today, CIMI Corp. finds that almost half of all enterprise change management practices fail to cover changes in cloud-hosted features.
To adapt change management and compliance policies to the cloud, follow these rules.
Rules to adapt current processes
Rule 1: Work with what you have
Adapt current change management and compliance policies and plans rather than creating new ones. The problem with current plans is their scope rather than their actions. In cloud deployments, factors can influence application stability and QoE that were never present in pre-cloud deployments. The goal is to ensure these factors are now included.
Rule 2: Capture every change
Cloud change management policies must capture all changes in cloud service contracts, service commitments and billable changes in the cloud. Not all cloud changes will require changes to software or repository-controlled middleware, and some may not be routinely tested. For example, changes to cloud hosting regions or to scaling limits will have no effect on software, but they can harm QoE. Treat all cloud changes as software changes and mandate the same level of stakeholder buy-in. To follow this rule, link cloud service responsibility to the software testing process explicitly.
Rule 3: Evaluate workflows
Consider workflow changes in change management policies. A workflow represents message exchanges from the user through to the applications being accessed and the network connectivity needed to support these message exchanges. Cloud applications are typically made up of multiple components. Some components move into and out of the cloud due to cloudbursting and failover settings, and the use of more complex technologies, such as service mesh, steers work. Changes to any of these things can alter stability, security and QoE directly. Since the cloud provider, the internet, the corporate VPN or any combination of these things provide network connectivity, quality of service can create a second level of impact.
Once you've covered the sources of change that non-cloud change management practices likely miss, you must still decide how to integrate them. The goal is to modify current practices and procedures. A good place to start is to plot out the application development, testing and deployment cycle. Put an arrow on the flow at each point where change management is currently applied. Then take the new change sources and decide where each can be mapped into the flow.
Perform testing
The stakeholder experience is lost when cloud change management is done on a unit-test basis. Depending on application design and deployment models in place, there may be subsystem tests that could be valuable.
To determine whether that's the case, follow this process:
Step 1. Move back from the application integration testing point, earlier in the change management flow, to each testing point.
Step 2. Evaluate whether there's a combination of sufficient functionality assembled there and significant exposure to new cloud-related changes to justify a meaningful stakeholder review of results.
Step 3. Stop at the point where that's no longer true.
Actual change management procedures are unlikely to require much change if this process is followed.
