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.
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.
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.
There are three common ways in which our customers start to ask the right questions:
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.
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.
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.
What did Jenny’s original roadmap look like? Given the business pressures that WealthGrid faced, the first actions her company took were around strategy.
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.
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.
Defining a high-level transformation path as the very first step helps set the right course through an uncertain environment.
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.
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.
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.
When someone has an idea that requires validation, the costs of doing experiments around it needs to be as low as possible.