Cloud is not a destination. It is a new and better way of doing things.

How do you define cloud?

Seems like an inane question, right? How do you define cloud? Seriously? Everyone knows what cloud means, right? But think about it for a moment. Ever watch a business channel like CNBC and see someone like Jim Cramer extol the greatness of a particular company’s progress “in the cloud” and find yourself yelling at the TV? “That is not a cloud, that is Cloud-washing!” you scream. Just me?

Or, how about when you are having a conversation with a peer, client, partner or vendor and the topic ultimately turns to cloud. How often have you discovered shortly into this topic, that when they say cloud and you say cloud, you are not talking about the same thing? For us, it seems like a daily occurrence.

In fact, we would wager that if you asked 100 random Fortune 500 IT leaders to provide their definition of cloud, a frightening number would describe something that could best be described as a virtualised IaaS environment. Some of the more thoughtful answers might include terms such as “multi-tenant,” “infrastructure as code” and “automated provisioning.” The point is that the overwhelming majority of those asked would likely define cloud through a technological lens. Technology is, of course, essential to the definition of cloud, but it is not sufficient.

How to think about cloud

Before we get into defining cloud (and we will), it may be helpful to discuss how best to think about it. Unfortunately, too many people think of cloud as a destination – to them, it is a noun. More appropriately, cloud should be thought of as a verb. In other words, cloud is what you do!

What do we mean by this? In practical terms, cloud is a different operating model for IT, where infrastructure becomes code, functions become fully automated and both infrastructure and application code are launched into live production environments without the constraints of some ridiculous release window. Cloud is also a world where human error and inefficiencies are virtually eradicated.

Why this actually matters

Almost without fail, our clients come to us after they have tried to “move to” cloud, only to experience some significant degree of pain and despair. As you might suspect, our first endeavour is to better understand the work they have already done, and launch a root-cause discovery for why it is not working out the way they projected. We have written many times in the past about the usual blockers, so I will not rehash them here. Suffice it to say, the one root cause we see that is more destructive than any other to the success of a cloud transformation is the failure to understand that cloud truly is a new and better way of doing things.

Let us do a little test to see if your organisation is struggling with this nuance. Our partner, Hewlett Packard Enterprise (HPE), has established a best practice called the Cloud Business Office (CBO). Think of a CBO as a decision-making body of all functional leaders who are stakeholders (whether they know it or not) in the outcome of a cloud transformation. As you can see in figure 1 below, there likely are more stakeholders than you may have considered.

Cloud Business Office (CBO)
Figure 1: Cloud Business Office (CBO)

OK, here is the test. If your organisation is struggling with your cloud transformation and you are having a difficult time figuring out the full extent of why that is, please go ask the leaders (separately) of all the functions involved one simple question:

Why are we doing this?

Do not be alarmed by the lack of coherent responses, nor by the misunderstandings and disconnections you hear in the responses. Some leaders may even look at you like you grew a second head. We can safely say, you are not alone. Yet it is essential that leadership have a common understanding of the definition and total value of cloud for an organisation to avoid self-inflicted pain along the way to cloud adoption.

OK, so how do you define cloud?

If you are still reading, we can safely assume some (if not all) of these points apply to your organisation. However, the definition of what it means “to cloud,” is really somewhat specific to the goals of each organisation. So rather than punting on the definition, let us help you define what “cloud-ing” means to you and your organisation. Regardless of how detailed your definition becomes, every definition should include the following parameters:

  • People and Process
  • Economics
  • Technology

Remember earlier when we mentioned that most IT leaders default to technical answers? That is why it is very common for them to overlook the single biggest challenge to the success of the journey to cloud: People! Yet people — and process — must be at the heart of your definition. Here are a few questions to help determine whether or not you actually cloud:

People and Process:

  • When your Developers want to provision services on demand, can they do so automatically – without the need to fill out a help desk ticket?
  • Are your Developers capable of pushing live code into live environments without bringing them down during a release window?
    If so, would your Operations team allow them to?
  • Do the offices of the CISO and Governance Risk and Compliance (GRC) not only condone your cloud transformation, but advocate moving even faster?
  • Do you have automated controls in place to ensure that you are not only in compliance today, but can also maintain compliance continually?
  • Does Finance understand how to manage a world with open POs?
  • Does Legal understand they will not get unlimited limits of liability from the major cloud providers?

Cloud Economics:

  • Are you paying only for what you use? Not just with AWS, Azure and/or Google, but with your SaaS applications and even with your on-premises hardware?
  • Do you have automated controls in place to ensure all workloads are continually optimised economically?
  • Can you automatically reconcile actual cloud spend back to the projections outlined in your original business case?


  • Are you using the truly transformative services cloud platforms offer today, or did you simply lift and shift VMs out of your data centre into AWS, Azure and/or Google?
  • Do you have a strategy to untangle your application landscape mess and refactor applications to take advantage of the latest technologies?

Remember earlier when we mentioned that most IT leaders default to technical answers? That is why it is very common for them to overlook the single biggest challenge to the success of the journey to cloud: People! Yet people — and process — must be at the heart of your definition. Here are a few questions to help determine whether or not you actually cloud:

Of course, this is not an exhaustive list, but in the interest of brevity, you can see where we are going. If you answered “no” to any of the above questions, you are not getting the full virtue of “cloud-ing.” Please also remember that this really is a journey: we have yet to see any large, complex, heavily regulated organisation achieve cloud adoption in a day.

In an effort to be constructive, we would like to leave you with some basic tenets to consider, as you try to drive a common understanding of cloud:

  • People first. This starts with leadership. If your leadership team does not have a common understanding of why you are adopting cloud, the masses will not either, and you can count on serious trouble ahead.
  • Only pay for what you use. Whether it is with public cloud, SaaS applications or even on-premises hardware (yes, even on-premises hardware), demand cloud economics from every vendor in your supply chain. If they cannot provide this, look elsewhere.
  • Do not mistake virtualisation for true cloud. Simply lifting and shifting VMs from on-premises into bare-metal servers on AWS, Azure and/or Google may have some virtue in limited scenarios — e.g., consolidating/shutting down data centres, or disrupting an outsourcing agreement coming up for renewal. But the true value of cloud lies in modernising applications and platforms to take advantage of all that the cloud has to offer.

Final thoughts

By now, some of you may have noticed that one familiar issue is not part of this definition — yep, “public vs. private” (i.e., the destination). That is because it is truly irrelevant to your definition of cloud. All the virtues outlined above can be achieved in both destinations, so why fixate on them? Of course, your costs could vary — but all the automation and agility you are looking for can be achieved in either domain.

Lastly, you may have thought our use of cloud as a verb was tongue-in-cheek. We can assure you it was not. When taking on a massive organisational transformation, words really do matter. And it is essential to get the entire organisation to understand that cloud is what you do.

This article was originally published in The Doppler, published by Hewlett Packard Enterprise. Reprinted with permission.