No Application Left Behind on the Journey to Cloud

This post has been adapted from the 2021 DevOps Enterprise Forum guidance paper by Satya Addagarla, Anderson Tran, Mik Kersten, Rob Juncker, Betty Junod, and Sasha Rosenbaum.

Enterprises have wide technology portfolios that include revenue generating applications built on old guard standard technology stacks (e.g., IBM, Oracle) to dabbling in modern technologies such as those provided by today’s hyperscalers. Enterprises are aware now, more than ever, that they will be hard pressed to remain idle in a world where digital product and services delivery are becoming the new, main revenue streams in their respective industries.

In the No Application Left Behind guidance paper, we break down the case for change as we show that this vast portfolio of applications need not have any applications left behind as we guide you on how to begin your journey of transformation. In this post, excerpted from the paper, we’ll guide you through the executive pitch to help your organization navigate change when a complex set of technology must be maintained.

The Executive Pitch

You are a large enterprise seeking to address a technology and innovation edge to continue to succeed in your lines of business. You realize that keeping up with the pace of new tech companies in your space will require a much more rapid pace of innovation and a shift to cloud.

Enterprises should take this challenge from inception to board acceptance, and we provide examples of what can be done to deliver on these goals for your organization. “No App Left Behind” is a theme on a treatise of transformation, where like-minded individuals commonly look like rebels against a common bureaucratic and slow-changing delivery model—and our desire and chase for improvement results in a paradigm shift that impacts people, process, and technology across our complex organizations.

Our intention is to prepare you with a foundational understanding of how to build a tenable case for DevSecOps and cloud transformation—guiding large enterprises on a journey to embrace the complexity of their present reality and rethink it into the future. For all of us in the large enterprise space, “No App Left Behind” is much more than a case for hasty lift-and-shift. The change to your technological landscape will impact how your applications are built and maintained long into the future—many core line-of-business applications may look nothing like they were before transformation.

The common argument for cloud and DevSecOps transformation begins with a goal to exit the business of self-managing datacenters, among other mostly cost reduction drivers and innovation, to fuel the business through expanding market share and new revenue streams. However, the story of cost reduction should not stop with using a cloud provider as a means to migrate hardware management—that will taper off in value. In fact many IT executives struggle to commit cost savings with this approach. Rather, focusing on a few key dimensions is more effective to build your business case with your board.

• Technology stack: Envision and source tech solutions for your business in your new future.
• Operating model: Self-contained and empowered teams with DevSecOps practices as key
  underpinnings.
• Governance model: Transform to a lightweight and agile governance model to accommodate larger volume of releases in a safe and secure model fit for your enterprise.

Cloud providers will bring new technologies that were not possible before, without heavy engineering and operational overhead, and can provide a shot of adrenaline to your business. The force multiplier to your technological capabilities is akin to augmenting your workforce with thousands of software developers’ efforts to build technology solutions. With this, you have the benefit of focused shared responsibility models, enabling you to focus on what matters most: data integrity, security, and new revenue streams.

DevSecOps has already changed how organizations maintain and manage the business of software delivery. Enterprises that maintain their own technology workforces as well as those who rely on managed services providers (MSPs) will see new resources emerge as the technology responsibility is moved up the chain due to new demands for automation to replace tedious and complex low-level tasks. Use this opportunity to transform. Demand that your business partners and counterparts become product-focused topologies that address customer needs well into the future of digital products and services for your organization.

Transforming governance and compliance into a new and lightweight form is key to maintaining stability and security alongside a high-level of iteration and changes to your applications. You will need to promote concepts such as “failing fast” and  “minimum viable product” time-to-market capabilities to business and product owners to bet on assumptions and evaluate hypotheses faster. You need to prepare them for the rush of thought leadership transforming further across your DevSecOps supply chain than you had ever anticipated. Design thinking, systems dynamics, and finding your organization challenging the status quo at every turn makes such a transformation an ongoing and permanent one.

Remember a few things when planning your business case and executing your plan: This is not impossible, nor is this a futile waste of time. You are not too late to adopt, nor are you too rigid to adapt. Track value all along the way, and remain data-driven and focused on the long-term vision and impact of where you are taking your organization in transformation. Pivoting from initial plans is not a sign of failure but a sign of health and agility. Transformation enables you to keep up with a fast-paced changing technology world that is waiting for no one.

(Re)Defining Success for Your Cloud Journey

The way that we measure success for the cloud journey has a direct impact on the trajectory of that journey. Metrics that have the best of intentions, such as measuring individual productivity and maximizing utilization at specific stages, can often drive unintended consequences and behaviors. We have identified a common thread with successful cloud journeys in that they focus on measuring value. In contrast, delayed and disappointing journeys over focus on measuring costs and do not have a clear value metric.

In this section, we propose there is a single metric that should be the primary measure for your journey: time to value, or flow time, for your cloud-based value streams. Measure time to value and cost reduction will follow. Measure cost reduction alone, and you will end up with cost overruns with little value to show for all the effort and investment. 

In terms of the business case described above, we need to measure:

• Technology stack: Did we define and incrementally deploy a technology stack that is measurably reducing time to value (flow time)? An effective cloud platform and technology stack should enable a dramatic reduction in time to value for delivering new capabilities to market.
• Operating model: Is the new operating model driving business value more quickly than the previous one? Measuring flow is a leading indicator of business indicators such as revenue, retention, and cost reduction. 
• Governance model: In order to reduce time to value (flow time) to be measurable in days, governance must transform to be more automated and on demand. Removing the governance and compliance bottleneck on flow requires a combination of DevSecOps, security, and modern governance practices.

Consider this example shared by Justin Watts of Lloyds Bank in an episode of the Mik+One podcast. The bank was looking to reduce the cost of having customers procure mortgages. They attempted various efforts at optimizing the different stages of that process. Costs did not decrease in a meaningful way; they continued rising.

Lloyds then brought on board a lean expert who proposed an entirely different approach, one that centered around the speed and predictability of end-to-end flow to the customer. Instead of focusing on reducing cost, the lean expert proposed focusing on delivering customer value as measured by the time from the moment a customer filed an application to the time the customer received the mortgage.

This triggered a review of the mortgage value streams and the end-to-end systems that underpin them and their handoffs through various organizational silos. This led to proposals on how to reduce the end-to-end time from the customer’s not the business’s perspective.

As a result, the initiative saw a dramatic reduction [xx%] in the end-to-end time to receive a mortgage. Due to all of the waste and wait states that were eliminated in support of this, there was an equally dramatic reduction in the cost of providing mortgages.

Optimize for costs, and costs will go up. Optimize for time to value, and costs will go down.

In his excellent paper, Cloud for CEOs: Measure Innovation with One Metric, Adrian Cockcroft, VP Amazon Sustainability Architecture at Amazon, makes the same point for the journey to cloud. Focusing on the speed of innovation gets you cost reduction, happier customers, and a faster feedback loop with the business. Focusing on costs alone gets you none of those things.

Given how simple this sounds, why do so many organizations continue to use costs and other proxy metrics to measure their cloud journey? The problem is, the vast majority of enterprise organizations do not know how to measure time and value in a systemic or meaningful way. This is exacerbated by the fact that IT has been traditionally measured by how much cost savings it can generate for the same service, not as a business enabler. 

To measure value, we need clarity on what we are measuring and what metric we are using to measure it. Should we measure the speed of projects? The number of applications that have been migrated and how quickly? The number of story points delivered?

The answer here is no, those are all proxy metrics. The key metric proposed here is time to value (Flow Time), which translates to time to market or speed of innovation of what we are delivering to the customer. 

To do that we need to define the following three metrics:

1. The product value stream that we are measuring. Every product value stream has a customer who is pulling value for that value stream and a set of teams supporting that value stream. To measure the speed of innovation, we must be able to measure the end-to-end flow of value for that value stream. 
2. The flow items that flow along that value stream. These must represent the flow of value that is meaningful to the customer and to the business. For this we can use the four Flow Items from the Flow Framework® (features, defects, risks and debts). Customers predominantly care about features and defects, as that is what is visible from their experience, but each value stream must balance risk (security, privacy needed to transform governance) and debt (tech debt, infrastructure debt) to sustain delivery.
3. The end-to-end flow time. This is a measurement of how long it takes to deliver flow items across this value stream.

Optimizing the entire cloud journey around reducing flow time for each value stream involves applying the theory of constraints to that value stream. If a value stream cannot deploy independently of meetings and discussions with an infrastructure team, chances are you have a bottleneck there that needs to be resolved. If security review takes weeks, you will never get down to the flow time of days needed for rapid A/B testing. If design, UX, or business approvals are an upstream bottleneck, it does not matter how good your DevSecOps and SRE practices are, there won’t be much value making it into your daily deployments. 

While the first step here is applying the theory of constraints to your value stream by measuring flow time, the journey does not end there. Recall that the three ways of DevOps are flow, feedback, and continual learning. By focusing on flow time, you create the conditions for each of those three. Fast flow means fast value to the customer, which translates to fast feedback for the teams and fast learning for the business as a whole (enabling fast failure and minimal viable product [MVPs]). 

For example, if a set of features did not improve retention or customer Net Promoter Scores (NPS), perhaps there is a design problem or a competitor who has already outpaced you in this market domain. The sooner that feedback gets to the business, the faster the learning and pivoting needed to survive and thrive in the move to cloud.

While making the reduction of time to value one of your main objectives, and the measurement of flow time the key result or metric that you track continually, it is still worthwhile to keep your eye on the cost metrics. The process, handoff, automation, governance, and software architecture improvements required to reduce flow time will result in a dramatic reduction of wait states across the value stream.

With that reduction, development becomes much more efficient, because developers and other technologists are not waiting in frustration on dependencies with other parts of the organization.  Given that development and headcount costs dominate hardware and hosting costs, the resulting cost reductions will be far more dramatic than anything involving the optimization of infrastructure or cloud providers. While that is still worth doing, it is via flow time that you will see not 2x but 10x improvements for your business. 

Next we’ll talk about the planning phase of your journey to the cloud…

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•