5 Essentials for Successful Cloud Adoption

In this post, I’ll detail five essential principles for successful cloud adoption. Note that while I am biased towards Microsoft Azure, these essentials are the same for cloud projects targeting Amazon Web Services, Google Cloud Platform, and so on.

Cloud adoption experience

I have had the opportunity to work with public and private sector clients during their cloud projects, working as a Principal Consultant with a focus on Azure governance, security, management, deployment, and migration. The range of experiences from those projects has taught me and my colleagues quite a bit.

What is a cloud?

The American National Institute of Standards and Technology (NIST) has an awesome definition of cloud computing. In it, they define the 5 essential characteristics of a cloud:

• On-demand self-service: Developers and operators have the ability to deploy resources and configurations as needed, without having to create work requests from a central provider.
• Broad network access: Services and features are available over wide types of media and with sufficient connectivity.
• Resource pooling: Many tenants share a huge pool of resources.
• Rapid elasticity: You can use as little or as much of the pooled resources as you need for your current requirements.
• Measured service: You pay for what you use, while you use it.

Cloud adoption versus cloud deployment

There is a huge difference between a deployment or migration project and cloud adoption. I have been a part of and seen projects where a client has successfully deployed to the cloud or migrated their data center to the cloud. There were (virtual) high fives, lots of great feedback, satisfied customers, and happy consultants. And then a year or two later, we start to hear that something isn’t right.

The people running the new cloud footprint, IT Operations, have locked things down and have tried to run the cloud just like the data center that they left. Even though they left the data center behind, they didn’t leave their way of working there.

The result is unhappy developers who were led to believe that things were changing, and they now refuse to adopt the new cloud footprint. And that leads to unhappy stakeholders (the business) because they aren’t getting the agility and fail-fast projects that they were promised.

Shadow IT isn’t dead

The first characteristic of a cloud, on-demand self-service, is probably the most important one for an organization. Businesses want agility – the ability to quickly deploy new services or workload features. When a workload owner or sponsor asks for something, the operators and developers working on that project or product need to react straight away.

The last thing that a business wants for the developer that is supposed to be creating the next great workload is to be stuck in weeks-long cycles of opening a ticket, waiting, explaining the request, waiting, updating the ticket, waiting, and so on. But that’s what happens with many organizations that migrate to the cloud – and then something unexpected can happen.

When you think of shadow IT, you think of developers going to the cloud outside of the control of IT Operations. But guess what? When developers are in the cloud and IT Operations have locked things down, those developers are going to start working in another cloud or tenant.

These developers are going to explain to their sponsors or the stakeholders that IT Operations are holding them back and that they need to find other virtual places to work. This results in IT Operations running the legacy systems only, and developers creating new workloads and storing data outside of security and governance frameworks. This leaves the business at risk, and this is definitely a lose-lose situation.

Cloud inertia

Another type of adoption failure is possible when there is a disconnect between the organization’s leadership and IT staff (development and IT Operations). I’ve heard of scenarios where leadership signs a contract with a cloud provider and then instructs their IT staff to “use the cloud”. OK, sure, but what are they going to do with it?

A few years ago, I met some staff from a huge American financial services company that had that edict: The staff spent a lot of time with Microsoft and still didn’t know what to do with their Azure contract. They had no direction from leadership and this vacuum prevented movement.

5 essentials for successful cloud adoption

Here are the five things an organization must take care of to increase the chances of successful cloud adoption.

1. Organization leadership must be actively involved in the project

If there’s one thing that I can get in a new client project, it’s to make organizational leadership involved in it. I’ve already pointed out two issues:

• Cloud projects that are led by IT Operations will lead to adoption failure.
• Directionless instructions of “use the cloud” will lead to inertia.

Organization leadership must be educated about what the cloud is and what it can do for the business. The CEO and CTO do not need to be cloud architects, but they should understand how the cloud can positively impact their business, their operational efficiency, their competitiveness, and profit margins. With some awareness, executives can be engaged to understand what they want the cloud to do for the business.

There’s also something that we techies tend to ignore – understanding the business motivations. Once the leadership documents and communicates what they want, those instructions can be converted into the technology and other changes that are necessary to achieve those goals.

2. Staff should be engaged in the project

If you want a cloud project to fail, then you should ignore the IT staff in the organization. These are the people that understand the existing workloads and data (the digital estate). These are the people that will run or ignore the new platform. These are also the same people that can be scared of change because they don’t understand the cloud, don’t have cloud skills, and fear that this is a new form of outsourcing that will replace their roles and make them redundant.

When leadership has documented the motivations of the business, they must document the high-level roles and responsibilities for the coming project – this may span internal staff, existing service providers, and consulting companies.

Instructions to all parties should be given in clear communications that explain why a change is being made, who is doing what in the project, and the expected destination of this journey. But most of all, the communications must excite and engage IT staff, letting them know that they are going to be supported and educated and that their careers will not only be safe but enhanced.

3. People and processes must be modernized

Stop me if you’ve heard this before: The cloud is not where you work, but how you work.

You can build the best footprint in the cloud, and have the most amazing migration ever, but if you treat the cloud as your old on-premises data center, then the business will never experience what the cloud promised. Digital transformation is 20% technology and 80% people and process.

An organization must look inwards to re-evaluate how IT services are delivered to the business. Traditional boundaries that prevent cooperation and exist with disparate leadership, goals, ticket queues, and ambitions must be broken down. New logical boundaries based on workloads should be constructed, with skills spanning multiple pillars (development, security, and operations) and a single backlog of tasks for that workload, working as a single unit.

Central expertise can be created in the form of a cloud center of excellence to guide the new teams. This shared expertise, coupled with a smaller team that is self-sufficient and capable of using the on-demand self-service feature of the cloud, will create a more agile environment to help the organization realize what the cloud was always meant to achieve.

Once the way of working is decided, roles must be described with tasks to be done and skills that are necessary. The roles should have names allocated to them. Skills gaps for existing staff should be identified to create a training plan. That training plan should be agreed upon, communicated, and scheduled immediately – not after a consultant is handing systems over.

Where there is no internal staff to handle roles, either new staff should be hired or managed services providers should be contracted to partner with the IT staff. Once again, those decisions must be acted upon before ownership of production systems in the cloud is handed over to the business.

4. Governance systems should be implemented

On-demand self-service can sound scary: The business requires control to stop runaway spending, keep systems and data secure, and stay compliant with industrial and regional regulations. Meanwhile, the freedom to innovate is required to give the business the results that it desires.

A balancing act must be struck between freedom and control. Governance systems can be implemented to allow necessary liberties that are guided by rails:

• Cost management can be used to track spending, optimize how resources are billed, give stakeholders and finance visibility, and create budget alerts.
• Required and desired configurations and behaviors can be audited.
• Undesirable or desirable resources or configurations can be forced or denied.
• The use of infrastructure-as-code with Git repositories, coupled with read-only access to production resources will introduce standardization and quality control with built-in detailed documentation and rollback systems.

5. A Cloud Adoption Framework should be used to run the project

As one might imagine after reading this article, there are a lot of things to consider when starting on a journey to adopt Azure, AWS, GCP, or similar. As I said earlier, I have a bias towards Microsoft Azure. I know the Microsoft Cloud Adoption Framework (CAF) and I like to use it. But I also know that both AWS and Google have their own cloud adoption frameworks.

The Microsoft CAF is a set of documentation that gives you structure, guidance, and advice on how to run a cloud journey project. To be honest, I find that some sections are too high-level and others are too “management consultant-like”. But what I like about the Microsoft CAF is the structure; it’s a set of items that I can put into an agile backlog and break down into tasks as the project progresses. It gives me a vision of the future and the client confidence that there is a structure in what can be quite a scary project for them.

Everything that I have discussed in this document is covered in the CAF either explicitly or implicitly:

• Strategy: This entire phase focuses entirely on the business, understanding motivations, and starting the process of translating those motivations into instructions for the next phase.
• Plan: This is where the IT staff first becomes engaged in the process. The digital estate (workloads and data) is identified for later migration, people and process planning is done, and a plan for the remaining project is created.
• Ready: A detailed design is created for the cloud deployment, and the governed footprint is deployed. That footprint is expanded or customized, and best practices (Microsoft Well-Architected Framework) should be applied before handover to production.
• Adopt: New workloads are innovated, and a per-workload iterative process is done to migrate workloads/data from the digital estate to the cloud.

Summary

If you consider that the cloud is meant to change your business, then you will understand that one must step back from the technology precipice before making that jump. Only once you understand what the business wants and how to facilitate those motivations should you start making decisions and deploying.

That might mean a few days of work for a small-medium business, or months of workshops and documentation for a large organization. However, it will mean that you have done the work to steer the ship towards the correct star.