4 defensive ramparts on the way to the cloud: Why can't you overcome them without a strategy and roadmap?

A minor digression on military expeditions

Cloud adoption is similar to a military campaign - a skilled warlord knows that technical superiority is not enough. There is no long-term success without very careful and well-planned logistics. Why? Because:

• the infantrymen were not hampered by hunger and cold (human resources),
• tanks and aircraft ran out of fuel and ammunition (finance and instruments)
• unbound Communications between the various troops and the command,
• the command had sufficient and true Information from the battlefield,
• the troops were correctly Motivated by,
• etc., etc.

The best technical equipment will simply not be enough if the military lacks it:

1. elementary strategies of what he wants to achieve,
2. very thorough planning (roadmap) of individual activities, especially the supporting ones.

At the beginning, the journey to the cloud does not resemble a military campaign, but only seemingly so. The cloud (like the military enemy) retains a certain degree of stealth. If we don't want any surprises, we must first get to know it as best we can and, with a well thought-out strategy, overcome several strategic defensive ramparts. I'll tell you which ones they are.

The first defensive rampart: I understand how I can use cloud technology, and I'm motivated to do so

At the beginning, it is important to know whether we want to go or invest in the cloud at all. We usually start with technical considerations on how to get into it in the first place. How do we adopt things that are similar to on-premise, and how do we adopt those that are like from another galaxy (at least initially) - typically PaaS, automation, PAYG, 3YRI, ...?

The old rule of "show pays" applies here and you need to delve into experimenting and playing with the possibilities of the cloud. It is certainly good to learn from others. Interesting tips can be found, for example, in Cloud Encyclopedia.

Often we do not experiment because we are dreamers who like to play with new things, but simply because we have no choice. Typical cases we have had to put up with historically are collaboration apps à la Slack, MS Teams, Cisco Webex or Google Hangouts. You won't find these in any form other than cloud, and so we have to deploy the cloud for them.

Experimenting with the cloud (whether by choice or by compulsion) is essential in overcoming the first wall of defence. Overcoming it will become an important foundation on your journey.

The second defensive wall: I understand the on-premise/cloud differences and know what I want to use the cloud for

By overcoming the first wall of defence, we usually start to understand the differences between cloud and on-premise. So we start to consider whether it is worth going to the cloud and with what.

We're getting to the math "1 + 1 = 3"which means we're going to have two environments: on-premise and cloud, plus it's all integrated. And that we're going to have to deal with three types of applications and infrastructure: with you:

• that doesn't fit in the cloud at all,
• that fit right in,
• that we're not sure where they belong.

We explained this problem in more detail in the previous article.

These considerations will help us to clarify, what we would like to use the cloud for and how. We will also make it clear what we will not and do not want to do with the cloud.

And here we will no longer doubt that the journey to the cloud is not just one of many IT projectsbut that this is a fundamental change. These realisations mean overcoming the second wall of defence.

Third defensive rampart: Without adoption, the cloud effect won't be what we want

The implementation of new technologies is associated (in addition to the actual technical deployment and integration into the existing IT environment) with the need for adoption. Adoption by the people who will use the cloud technology and adoption of the technology into processes.

It is important to understand that cloud deployment is not just one technology, but the whole platform comes with a set of technologiesthat are integrated with the platform control system. Using a cloud platform means:

• gaining a set of advantages - automation, single catalogue, integrated technologies,
• accepting limits - I can only set some platform parameters (others not).

The implications can be seen in the collaborative cloud SaaS platforms M365, Gaps, Webex. We are excited about the innovations that the provider continuously brings, but the changes have a life of their own. We can only choose, if we adopt the changes now or a little later.

Integrating a cloud platform into our IT environment also commonly means that we can customize adapt only certain areas of the processeswhile in many other cases we have to adapt to the platform.

Examples of adaptation are cost management and capacity planning. In on-premise, capacity planning once a year and budget control quarterly is sufficient. In the cloud, we need to do capacity planning at least quarterly and budget control on a monthly basis. The IT team needs to be prepared for all of this - experience-wise, process-wise, organization-wise.

Recognising the need devote significant energy to cloud platform adoption we're gonna get past the third wall of defense on our way to the cloud.

The fourth defensive wall: The phenomenon of clean-up - bigger than we can imagine

The most complex and difficult defensive wall to overcome on the way to the cloud is the phenomenon of cleaning. We have to accept the fact that we will be fixing things that are not directly related to cloud deployment, but if we don't fix them, cloud deployment will be either very difficult or even impossible.

The scavenging phenomenon cannot be avoided, as it stems from the fact that IT cannot come to terms with its history at 100 %. Why? We do not live in a perfect world in IT and there are always:

• architectural debts in applications and infrastructure,
• technologies that we wanted to get rid of but didn't have the time or budget to do so,
• unfinished change projects,
• non-optimised processes,
• etc., etc.

Yes, such problems always exist in IT and the need to clean them up often emerges only in the middle of a big project. With a smile, I say that every big project should not be judged by its own change, but by this, how much cleanup of the neighborhood the change will force.  

The cloud is a big change, which is why the phenomenon of cleaning cannot be avoided. Count on it right from the start, prepare for it and try to plan and manage it. The most painful thing is to find out that you are forced to clean up as you go along and you didn't plan for it in the project schedule or budget.

You can't do it without a strategy and a roadmap

You can probably see my comparison of cloud deployment planning to a military campaign. How do you answer the question: Why is a strategy and roadmap necessary for going to the cloud? Because only through them:

1. you'll be clear about your own motivations and know how to use cloud technology, 
2. Understand the differences between on-premise and cloud and what to use the cloud for,  
3. Plan the right mix of adoption action steps, organisation and processes for cloud deployment, 
4. define the remediation and cleaning steps you need to take to use the cloud effectively, 
5. confirm which regulations you must comply with if you are a regulated entity. This point is specific and I will address it in a future article.

If you conquer all of the above mounds, you are halfway there. A defined cloud strategy and roadmap will significantly increase the likelihood of your success on the road to the cloud.