In my previous role as CTO with Liberty Mutual we had a familiar challenge: how do you develop faster? It would often take months to get a big product out into production, our predictability of hitting deadlines was poor and we needed to move faster. We also had challenges around scalability. We would get spikes whenever there was a natural disaster or every year on Cyber Monday: people would buy a car on Black Friday and then they would buy their insurance on Monday. It took a lot of manual effort to ensure the systems could handle those spikes.

So in 2014, we started the dreaded digital transformation with a focus on three key areas: customer centricity, cloud-native development, and agility. And me being an engineer, I focused in particular on cloud-native development. We wanted to avoid the trap that a lot of companies fall into when adopting the cloud where they just migrate their servers instead of modernizing their solutions to take advantage of the strengths of the cloud.

Migration vs Modernization

A lot of companies shift from their own data center to Amazon's data center. They get the advantage of global scale, availability zones, and edge locations. But after the transformation is complete, the consultants have been paid, and the bonus pool has been emptied the CEO or the board usually starts asking why our IT bill is higher than it was and things don’t seem to be moving faster.

Replacing hardware is just the start of what the cloud can offer. If you go up the stack you can start offloading things to the cloud provider like compute, storage, database, and platform management. This is the difference between migrating to the cloud and modernizing your systems to take advantage of the Modern Cloud.

We debated where we should draw the line for over three years at Liberty Mutual. We initially adopted an iterative cycle of migrate, measure, and then modernize. This developed into a strategy we call Serverless First. The idea is that for every piece of software you write, you look at a managed service first. If that doesn't work, you then fall back to what you need to do (containers then a Virtual Machine). We thought this novel at the time, but Werner Vogels, CTO of AWS, has since talked about it being “organizational nirvana”; companies that take a serverless first approach can offload unnecessary tasks to the cloud, and just focus on business value.

Identifying what to offload

I use a technique called Warderly mapping to plot the evolution of technology. This is a technique I've been using for about ten years now and it is like a secret sauce. You can map out a landscape and predict where the movement will be so that you can get a step ahead of it, which is crazy in technology.

The first step in creating a Wardley map is to identify the customer and their need, which in the case of a cloud transformation could be a board member and their goal is business value. The next step is to determine the components of the value chain that deliver on that need, such as the people, processes, technology, data, and more. For a cloud migration, examples include the technical vision, organizational culture, architecture standards, and best practices.

The next step is to determine the evolution of each component of the value chain and map these from top to bottom based on their contribution to the business value and from left to right into four categories: Genesis (Novel), Custom Build (Emerging), Product (Good Practice) and Commodity (Best Practice).

When something new comes along, it's really novel and exciting and we just want to learn about it. As we learn more we understand what is now possible so we custom-build a solution. Over time our understanding improves and we get good at it. And then it evolves to be a commodity. It's a best practice and we just know we need this thing.

Every technology and capability moves from left to right. So as you plot this value chain on this map as a team, you can identify the areas where it makes more sense to focus your time. For example, many teams create their own architectural guidelines but all the cloud providers have well-architected frameworks. You should use and extend these good practices rather than custom building your own.

By plotting out a map you can adopt what I call the Value Flywheel. There are four elements that feed into a self-reinforcing value loop. Clarity of purpose is obtained by identifying the business value which helps engineers to understand exactly what you're doing and why. This also helps to create an environment where people can speak up and challenge the thinking behind certain ideas because they have a mechanism of tying the work back to the business value. This environment fosters a strong partnership between product and engineering which results in better ideas and solutions for the business.

Training your engineers in the latest on cloud services will help you to speed up delivery by more quickly identifying the next best action. For example, whether it makes sense to custom-build some new business logic or whether you should adopt the latest managed services. And then finally, Long-Term Value. Your architects and technical leaders will ensure the quality of the build and direction, which help to reinforce the Clarity of purpose and continue the flywheel.

Challenges

There will always be some pushback when you try to adopt some of the managed service cloud offerings. I like to call these pushbacks serverless myths.

We’re different. Unless you’re building a competitor to AWS or Azure just use their tools. It will cost you too much to replicate their tools.

Fear of Vendor Lock-In. Speed trumps flexibility. You might eventually get portability but you also might be out of business because you failed to deliver business value.

Serverless is immature. Maybe in 2016 but not anymore.

Our engineers are not ready. This is more an indictment of your lack of training than of serverless. The cloud is constantly changing and improving so you need to invest in training.

It gets expensive fast. This is a risk and you need to mitigate it with FinOps and training.  Good teams know how much their software costs and will manage it.

Our security tools don't work. If your security is slowing down the technology adoption in your company, you need to educate security. That's not a valid reason against modernizing.

Benefits in Practice

I’ve seen many examples of Serverless First succeeding, but there are two great examples from my past.

Back in 2016, we had an idea to use chatbots. Most of the big vendors said they could give us a quote in about 12 weeks, but we decided that we would build a prototype in 12 weeks using a serverless first approach. We used Amazon Connect, which is a call center in the cloud, and we could rapidly iterate using AWS chatbot services based on Alexa technology.

We built a fully functioning, albeit simple, voice assistant and got that to production in 12 weeks. It was taking around 150 calls a month which is tiny for a large enterprise, but it was working and live. From there we continued to iterate improving the quality, adding in more conversations, and ramping up traffic. We were getting really low call deflections and really low callbacks which proved that the bots were providing a fantastic customer experience.

Then COVID hit, and claims stopped coming in because people stopped driving their cars. Because this was a serverless cloud-based call center, it scaled down with less traffic and our cloud costs dropped (less traffic means a lower cloud bill with serverless).

On the flip side, overnight there was a decision to make a lot of outgoing payments for policyholders. Our outgoing payment system needed to ramp up, but luckily it was also a serverless system. It handled the extra and unpredicted traffic with zero tweaks.

One scaled down with a lack of traffic and the other one scaled up. Two completely unpredictable situations, but the systems handled them without extra changes.

Embracing the Future

Back in 2016 we Wardley mapped out the entire technology landscape. We didn't put a date on it but we obtained clarity on what we had to invest in and what we didn't want to invest in. We needed to focus on the customer experience of the voice assistant and the scalability of those systems. Our next best action was to make everything serverless, which meant that when scale came, AWS handled it.

We used a well-architected process all the way through to make sure we had security, cost optimization, operational excellence, reliability, and performance. These benefits were all baked into our products right away.

Hopefully, you can adopt the Value Flywheel in your organizations to get clarity of purpose, create an environment of success that encourages innovative thinking, map your landscape to help make the next best action clearer, and ultimately focus on long-term value creation.

—

You can learn more about adopting a serverless first mindset at https://theserverlessedge.com and you can learn more about the Value Flywheel Effect by reading the book: https://itrevolution.com/product/the-value-flywheel-effect/