Got Cloud in your CAB? Top Tips to Reach Cloud-Change Nirvana

03/08/2017 by: The SunView Team

Change management can be a delight in the cloud but it can also be a challenge. To reach cloud-change nirvana, you first need to understand the clouds your company uses and how these integrate to provide IT and business services. Sounds obvious, doesn't it? But it's amazing how few companies do this. Just focusing on the cloud services the corporate IT organization procured isn't enough as, according to Gartner, there will be shadow-cloud usage that IT doesn't know about. Have your IT pros grasp what cloud services are being used, by whom, and how?

If you can get a real view of your cloud situation, then you're within reach of cloud-change nirvana and you can leverage cloud to delegate changes to your cloud providers and use modern change techniques to improve your change management.


A brief history of change management and adapting it for cloud

IT service management (ITSM), and its processes such as change management, started life in the 1980's. Companies worldwide have adopted ITSM best practice and developed capabilities such as change advisory boards (CABs), cross-organizational teams responsible for giving green or red lights to proposed changes.

In 2005, change management and the CAB were described in the Visible Ops Handbook as "like the brakes on a car, they let you go faster," but with cloud the car is also transforming as you drive. Public cloud services are constantly updated by the service provider and often without your permission, with infrastructure treated like cattle not pets. It's probably all enough to give CAB members the shivers.

There are three critical points to understand when performing change management, and using a CAB, with cloud services:

  1. Understanding your cloud exposure
  2. Mapping the interactions with cloud from a service perspective, then
  3. Using cloud services to offset change process.

1. Understanding your cloud exposure

"Cloud" is an umbrella term for a wide range of services, from business-to-consumer (B2C) services - think Spotify, Gmail, and Dropbox - to business-to-business (B2B) services - think, Amazon Web Services (AWS) and Microsoft Azure. None of these services are identical, but they're all called cloud. And it gets even more complicated.

An organization that says "We use AWS" isn't saying much, because there are more than fifty services within AWS! Are you renting virtual machines (VMs) from AWS (and doing a lot of ops yourself) or are you using Lambda (serverless infrastructure)? These are two completely different types of services, with different service management profiles that affect things like change management.

It's a shrinking population that isn't using cloud today and enterprises are using a variety of methods to really get a grip on their cloud service usage:

  1. Working with finance to capture any corporate expenses paid to cloud service providers such as AWS. Identifying the teams and individuals concerned. Possibly moving to rejecting any claims that are not pre-authorized.
  2. Asking IT to monitor corporate internet traffic to identify the use of B2C cloud services such as Dropbox as well as B2B cloud providers such as AWS, Azure, and Google. Identifying the individuals and reconciling this access with known projects.
  3. Getting the internal ITSM or help desk systems to tag issues, problems, and changes related to cloud services - to analyze the exposure with cloud services.
  4. Reading something like the Rightscale State of Cloud Report and running your own internal staff survey to get a read on what the company thinks it's doing in the cloud.
  5. Making one executive responsible for reporting, but not necessarily controlling, cloud usage and spend. Visibility is crucial here.

This information can feed into the CAB and will improve both understanding and decision making.


2. Mapping the interactions with cloud from a service perspective

Clouds are the province of the tech world. Tech persons immerse themselves in application programming interfaces (APIs), managing "infrastructure as code," and they can weave cloud services together to create new business processes on the fly!

For this reason, it's natural to try to understand change from the cloud-perspective - a bottom-up approach where the cloud is the center of the techie's universe. However, what your organization really needs to understand is how your business services map to cloud services, and how they interact to support your business processes and your customers.

Two examples for illustration, one obvious and one not-so-obvious, are:

  1. Your customer-facing website runs in AWS and uses a five separate AWS services glued together to form the website. These include the DNS service (Route53), the CDN service (CloudFront), PaaS (Elastic Beanstalk), and a range of management tools. Your CAB needs to understand how changes to these services impact your website.
  2. Your customer service team use a hosted help desk that's also integrated into Salesforce for customer relationship management (CRM) and Microsoft Office 365 for productivity - so it's three separate, but connected, cloud services. Your CAB needs to understand how these are managed and configured, how they are connected. Plus your office Internet connection is very, very important - no Internet connection, or poor Wi-Fi, will probably lead to poor customer service.

3. Using cloud to offset change process

If you understand the clouds you use and how you use them, then you are in good shape. And you are ready to move from "suffering cloud" to "exploiting cloud," to achieve that cloud-change nirvana! There are two more things to do though:

  • Recognize that Cloud is a shared-responsibility model. The higher-level the cloud service, the less change you are responsible for. Where possible, use high-level cloud services such as "database as a service" rather than "infrastructure as a service" and installing and managing your own database. Let the cloud service provider take the strain.
  • Modify how you apply change. Use code and APIs to document and manage infrastructure as code - making systems self-documenting, tickets auto-updating, and providing easy change implementation and roll back. All of this reduces the risk profile of changes and makes them simple, every day activities instead of big-bang, all-weekenders.

Cloud is complicated and can be chaotic if not understood in your organization. But harnessed correctly it can reduce the pressure on traditional ITSM processes such as change management. Using the above points, a change management team can improve their organization's ability to consume and manage cloud, and the new can work well with the old.

Ready to try ChangeGear for yourself?

Get Started

| Change Management