If you either joined our webinar in November, or have read our book Cloud Native Transformation, you have already met Jenny, our hero. Jenny is a middle manager at a fictitious mid-size firm, WealthGrid.
WealthGrid faces three distinct, competitive threats. The first comes from those in its industry who have already started to adopt Cloud Native. By doing this, WealthGrid’s competitors have already started to win the war for both customers and engineering talent.
The second threat comes from the plucky, digital upstarts like Starling Bank who went from nothing to having a digital bank in just one year using a Cloud Native approach.
The third and most frightening threat, however, is the one that WealthGrid can’t see coming. What will happen if one of the tech giants moves into WealthGrid’s space?
These threats drove Jenny and WealthGrid to adopt Cloud Native. They got it wrong twice before getting it right the third time. This blog post is about that third time.
Wealth Grid’s third try illustrates how we at Container Solutions typically help our clients be successful in their own Cloud Native transformations. Even if you are not one of our customers, this approach has worked for enterprises in a variety of industries and, we hope, can also help you.
3 Steps to Risk Reduction
A Cloud Native transformation means not just ‘moving to the cloud’. It means combining people, processes, and technology to fully exploit Cloud Native tech’s advantages, making your organisation more nimble and responsive to customer needs.
When it comes to Cloud Native transformation, there are three steps to removing risk from the process; we call them Think, Design, and Build. (There’s a fourth step, Run, but that’s a topic that we address more fully elsewhere.) The first step, Think, is all about asking questions. From questions come ideas and hypotheses, and the best of these can then be tested experimentally.
Testing experimentally is the second step. Once the results of the experiments are in, they can be compared to each other and the next steps can be plotted.
Finally, once experimentation has taken enough risk out of the process, you can ramp up and complete the transformation. This is the third step, Build, and it differs from the first two in one distinct sense: it is very expensive.
Cost and Risk
Step One of our process, Think, which involves coming up with questions and hypotheses, costs only time and imagination. Step Two, Design, for testing experimentally, has more tangible costs. Finally, Step Three, Build, means ramping up a full Cloud Native transformation, and is expensive, in both real and opportunity costs. Thus the time spent in the first two stages is never wasted. Unfortunately we often see firms trying to ramp up without having spent time first in thinking and experimentation.
In our book, Jenny failed the first time because she started at the wrong end of the process; she began implementing full-scale changes immediately. This quick and bullish ramp up was, of course, followed by an embarrassing and expensive ramp down; she had failed to stack the odds in her favour. Let us now start at the beginning of the process and walk through what Jenny eventually did do when she got this right.
Developing Hypotheses
There are three common ways in which our customers start to ask the right questions:
- WTF is Cloud Native? Like many others in our industry, Container Solutions provides a gamut of free, thought-provoking content, including blogs, webinars, videos, books and questionnaires. We want to help people avoid the classic mistakes that Jenny made. Remember, experience is a good teacher, but it’s both expensive and backward looking.
- Virtual Worlds. When a doctor works with their junior colleagues to help a patient, they do so in the virtual world of their imaginations. They consider potential treatments and consider their potential effects. So it is with Cloud Native. Using nothing more than a whiteboard, we want to ask and answer the right questions, considering what could happen.
- The Cloud Native Maturity Matrix. As IBM Garage’s Holly Cummins argued in last month’s WTF, a Cloud Native transformation is as much an organisational transformation as it is a technology one; moreover, the people problems are often the hardest ones to solve. Yet, organisations often focus on the technology. Our Cloud Native Maturity Matrix provides an overview of nine different axes that form part of a Cloud Native transformation and is a useful tool to start thinking about what is really involved.
All of these techniques cost hardly anything and none of them ask us to write a single line of code; you can download the matrix and accompanying instructions here.
Jenny got her Cloud Native transformation right when she stopped typing code and started asking the right questions. In fact, it was Jenny’s discovery of the Cloud Native Maturity Matrix that helped her begin to understand the challenge ahead. Remember, experience, no matter how wise, is backward looking. The questions the Maturity Matrix poses help us to anticipate the future. Ultimately the power of the imagination beats experience.
The Cloud Native Assessment
Those who are about to start a Cloud Native transformation can and do go quite far by consuming content, asking questions, and considering virtual moves in the virtual world of their imaginations. In doing so, they significantly reduce the risk of the work that lies ahead. This is (more or less) cost-free risk reduction. No feasibility studies. No trips to Silicon Valley. Just good old-fashioned reading, dreaming, and whiteboarding.
When ready, our customers move to structured thinking in the form of a Cloud Native Assessment (CNA). Although it sounds posh, in truth a CNA is really just a gap analysis. The output is a mapping on top of the Maturity Matrix, which shows where a company is and, of course, where it has to go. Here is the gap analysis from WealthGrid’s Cloud Native Assessment:
You can see that WealthGrid was miles away from Cloud Native. The results of WealthGrid’s assessment may have been shocking but it at least gave them a dose of reality. This allowed Jenny and her team to navigate a way forward, building a roadmap made up of Cloud Native transformation patterns.
Cloud Native Transformation Patterns
The second output of the Cloud Native Assessment is a roadmap that is made up of Cloud Native Transformation Patterns. A pattern is a known solution to a common problem. Patterns are designed by experts— in this case, by the team at Container Solutions—for use by non-expert users.
There are about 80 Cloud Native transformation patterns, each one captured on a card. This allows our customers to reason about effects, to consider virtual moves in a virtual world without spending very much money. This is known as the ‘design of action’, which is also known as ‘strategy’. Note, as this point in the process, not a single line of code has been written nor a single virtual machine provisioned.
WealthGrid's Original Roadmap
What did Jenny’s original roadmap look like? Given the business pressures that WealthGrid faced, the first actions her company took were around strategy.
- Executive Commitment. Given the scale of the transformation, WealthGrid needed to have the executives on board. This pattern is common to all successful Cloud Native transformations.
- Business Case. WealthGrid’s investment in Cloud Native was measured in millions. For this, a proper business case had to be prepared, which did the job of aligning the executives.
- Transformation Champion. WealthGrid is a conservative company, so it needed a full-time transformation champion to help popularise the move to Cloud Native.
- Value Hierarchy. Cloud Native relies on distributed decision making. For example, teams are empowered to make decisions closest to the action, rather than having to simply implement decisions made in the C suite. Having a clear value hierarchy enables distributed decision making. For example, at Starling bank, they value security, resilience and scale in that order. This means that Starling’s engineers can make autonomous decisions about architecture based on the value hierarchy.
A Series of Hypotheses
The team at WealthGrid went from thinking about Cloud Native, which cost them hardly anything, to some structured thinking, which didn’t cost much and only took them three days. The outcome of those three days was a gap analysis, roadmap, and a set of hypotheses. In return for their efforts, WealthGrid got a significant boost in context and situational awareness and therefore a significant reduction in risk. This marks the end of Step One.
Hypothesis Testing
The third output of the Cloud Native Assessment is a set of hypotheses that need to be tested experimentally. These hypotheses are usually about the current skill levels of the teams, a target set of applications that might be containerised, and the types of tools that might work in the company’s specific context.
This experiment phase—what we call Design—usually takes about 12 weeks. The goal is to learn. More specifically, when we are experimenting, we are building to learn. This means, once again, certainty is increased and therefore risk is decreased.
By the time we stop experimenting, at the end of the Design phase, we have significantly reduced the amount of risk in the Cloud Native transformation. At this point, companies have a good understanding of Cloud Native in their context, the tools that might work and their own capabilities.
Is this money and time well spent? Consider once more WealthGrid’s story. Its first two mistakes cost the company a lot of money. When WealthGrid followed the process outlined here, it cost a fraction of its earlier misfires. However, this cost allowed the company to stretch their remaining budget much further. This means, after the Design phase, rather than experience an embarrassing ramp down, they began a steady ramp up—to the Build stage, and a full-scale Cloud Native transformation. This focussed approach was cheaper and less painful. It was worth it.
Related Cloud Native Patterns
Vision First
Defining a high-level transformation path as the very first step helps set the right course through an uncertain environment.
Business Case
Before launching a Cloud Native transformation, an enterprise’s leadership must make sure the initiative is needed and that the benefits will justify the investment.
Gradually Raising the Stakes
In an uncertain environment, slowly increase investment in learning and information gathering; eventually you uncover enough information to reduce risk and make better informed decisions.
Options and Hedges
Research has created deeper understanding, and a few potentially promising transformation paths have begun to emerge. Continue reducing the risk by focusing on the most promising options and developing them further.
Reduce Cost of Experimentation
When someone has an idea that requires validation, the costs of doing experiments around it needs to be as low as possible.
Previous article
