In the last two blogs on this subject we talked about Cloud Native computing and about strategy. In this blog, we'll put the two together and consider Cloud Native Strategy - what it means and how to do it.

In our first post we defined Cloud Native as a toolbox of approaches (IaaS or PaaS, microservices, containerisation and orchestration) for helping with three potential business objectives:

• Speed - faster delivery for products and features (aka feature velocity or “Time To Value”).
• Scale - maintaining performance while serving more users.
• Margin - minimizing infrastructure and people bills.

We also said that Cloud Native strategies tend to:

• Start with a cloud (IaaS or PaaS)-like infrastructure.
• Exploit the strengths of that infrastructure.
• Leverage new open source infrastructure tools (like orchestrators) and new architectural concepts that have infrastructural impact (like microservices and containers).

In our second post we looked at seven key elements of strategy, including goals and actions we take towards them.

Overall, we highlighted the changes that cloud has brought to IT strategy by de-risking infrastructure decisions. Basically, the cloud makes it possible, or even preferable, to be more experimental and decide less up-front.

In this post, we are going to talk about how even with the more experimental and lower-risk Cloud Native approach it still remains critical to consider Jamie’s seven elements of strategy:

• Situational awareness.
• A shared goal.
• Risk.
• A working coalition.
• Self-supporting actions.
• A continuous process.
• Vision and willpower.

The cloud is a highly uncertain environment subject to constant change. It happens that in the cloud some decisions are less irrevocable and thus less risky than in a privately-owned environment. That gives us interesting new opportunities - but also generates some new threats.

Where Are You & What is Your Goal?

“Being Cloud Native” is not an end in itself, it’s merely the rocket by which you reach your ambitious destination of choice. A Cloud Native (CN) strategy allows you to achieve a defined business objective by exploiting cloud infrastructure and tools like containers and orchestrators.

We’ve talked about some common goals but every business must define its own objectives based on good situational awareness - understanding of both the opportunities and the issues the business faces. For example, right now is the most important goal faster delivery on new features for an established product? Or reducing operational costs? Or improving response times in new regions? You may have noticed that these are all business goals not technical ones. The value of a Cloud Native goal is generally to the whole company not just the IT team.

Dangerous Contradiction?

Some common Cloud Native objectives may seem contradictory. Don’t worry, that isn’t just you misunderstanding them - they genuinely can be. For example, Company A may need feature velocity and ease of development. They might choose a Cloud Native architecture that is slower to run and costlier to operate but is easy for a large team to develop on simultaneously and deploy to quickly. For them, that is success - their goals of quick and easy development are met.

Company B may prioritise site response times. They choose a Cloud Native architecture that gives them higher execution speed but makes development a bit slower and more difficult. For them, this is success - their response-time goal is met.

The lesson here is that choosing “Cloud Native” does not define your business priorities, you still have to do that through situational awareness. If a business has different priorities in different areas, which isn’t unusual, they may have more than one CN strategy and that is fine. One of the strengths of a CN approach is it can achieve more than one thing. However, that is also dangerous - if you’re not clear what goal you’re trying to achieve it isn’t obvious what you’ll get.

So the first step in a Cloud Native Strategy is review your situation and define your goal.

Fear, Risk and Cloud Agnosticism

A CN strategy often aims to be cloud agnostic - it doesn’t depend on any one unique cloud service or vendor. However, vendor lock-in is just another risk to be weighed up against potential advantages. A Cloud Native approach de-risks many infrastructure decisions by making them reversible but it does introduce new supply chain dependency risks.

The next step in your strategy is understanding what risks you are willing to take.

Action!

Every Cloud Native goal, such as a scale target, has many sub-goals and each may require its own strategy. Once you’ve decided on your overall objective, the first step is usually to identify a well-defined sub-goal and start tackling it with self-supporting actions. A simple strategy for a limited, clearly-defined Cloud Native goal within a single team or group might be to take very small, low risk, exploratory steps without a detailed plan and with frequent review of the results. Sometimes though, a simple iterative process is not enough. It is important to step back once more and gauge the difficulty of what you are trying to achieve. A lot of that difficulty will arise from the complexity of your working coalition.

Complex Working Coalition?

Some changes are easy to achieve - maybe a repetition of something we’ve done successfully in the past. Some are purely technical and low-risk, so a suck-it-and-see experimental approach can work without hard up-front thinking. But consider these questions for a moment:

• Does a change cut across organisational boundaries?
• Does a change require skills the team doesn’t currently have?
• Will the change create winners and losers, and therefore resistance?

If the answer to all of these questions is ‘no’, then a simple spreadsheet, a bit of common sense, a small team, and an experimental approach is very likely to be enough. If, however, the answer to any of these questions is ‘yes’, then this is a more difficult objective and you will have to form a cross-business working coalition.

Many companies don't realise this. They think of all Cloud Native change as purely technical change. They thus rely on existing management practices - read common sense and a list of straightforward activities - when what they need is something more powerful: a strategy.

Step Back!

When we realise our objectives are going to be tough to achieve, we need to step back and reconsider the classic components of strategy: our goal, vision and willpower, our current situation, the risks, our self-supporting actions and our working coalition. We also need to be aware that whatever we do there will be no glamorous big bang finale - this is a continuous process.

Situational awareness and Goal

• What is the detailed business goal we need to achieve? What are the benefits? Is it worth the effort? What is the compelling vision that will drive this campaign?
• What are the risks of this vision? Has anyone comparable done it successfully? How did they deliver? What is realistic in terms of change and timeline?
• Is there the willpower to drive this through?

Capabilities

• Where are we now?
• At a very high level, what needs to happen to get from where we are to the vision (what are the actions)?
• What cultural or organisational or capability changes will be required? Are the changes plausible? How can they be delivered?
• Who will win and who will lose out? How will we handle that?

Coalition

• The most important step is to build a coalition who genuinely want to deliver on the vision. Identify the key parties and influencers: are they convinced yet, can they convince others and do they have realistic expectations?
• Does everyone involved understand the goal and their part in achieving it?
• Are they committed?

Whilst building this consensus we probably want to get agreement on some concrete foundational stones of the project (self-supporting actions) that might be controversial and more costly to change later. For example, choosing a single cloud vendor or a multi-cloud approach.

Making any complex coalition deliver relies on having a compelling vision and considerable willpower. Cloud Native is a continual process - there is no “big bang” to aim for. There will be lots of small wins to celebrate but missteps too (this is all very new) and everyone has to remain motivated to keep going. For every company we have spoken to, Cloud Native has been a gradual process of years, there are no magic final release dates.

Conclusion

• Situational Awareness and Goals. With a Cloud Native strategy you need to work out what your business cares most about. Does feature velocity beat everything or does, for example, cost, scale or execution speed mean more?
• Risk. How much risk are you willing to take and what kind? Picking a single cloud vendor is a risk (they could fail or be hacked) but some are more risky than others. Building your own private cloud is a completely different kind of risk (it could be costly in cash or time). Every strategy has risk and every business has a different risk profile. Cloud de-risks key areas but introduces new supply-chain dependencies. Take a realistic view of the difficulty of the goal you are trying to achieve and act accordingly. If it’s easy, just use a simple, iterative approach. If not, you’re going to have to manage the execution of your Cloud Native strategy just as you would for any major business change.
• Working Coalition. The aim is for Cloud Native goals to be transformational so eventually they won’t just involve the tech team. Influencers within the whole organisation will need to be convinced, which means vision and willpower will be required. Cloud Native goals are not “big bang” deliveries so a long term commitment to gradual improvement via continuous processes will need to be established.
• Finally, self-supporting actions must be defined. For the tech team these may be things like “adopt continuous delivery” or “use containers for deployment”. Outside tech the product marketing team may need to change their processes to handle continuous, small deliveries with constant user feedback, for example.

In our next post we’ll talk more about the three most common business goals of Cloud Native: speed, scale and margin.

Read more about our work in The Cloud Native Attitude.