Agility and the Cloud

Agility is the key benefit of a CIO’s cloud-first strategy. It’s my key reason for advocating embrace of the cloud. When you’re the one who must find the solution to a problem, you’d like to implement immediately.

A Hard-Earned Lesson

I learned the need for agility through painful experience. This happened years ago, early in my cloud journey. When I first used the cloud with my customers, the cloud was primarily servers and storage. It did not offer the wide portfolio of cloud-native services that exists today. It was largely “somebody else’s computer,” as cynics like to say. Cloud computing was still a lot like legacy computing.

One of my customers had a small application built for a small number of users designed for a traditional server on a traditional hosting service. It ran fine for months. On a Thursday night (it’s always a Thursday night, isn’t it?) I get a call that the server is down. But it was not down. Sales had spiked and the subscriber count had grown. More subscribers meant more requests per minute, more demands on the server. A modern devops team would monitor this, but we lacked that capability at the time. We had three choices.

1. We could “scale-up” to a bigger server, but how big? And did we want to pay full price for the valleys just to cover peaks in demand?

2. We could “scale-out” to multiple servers if we could efficiently separate compute from storage.

3. Or we could try a relatively new architecture called “serverless” that promised exceptional scalability and resiliency.

Over a long weekend, we migrated the content and API to the new architecture. By Monday morning, the system was live and resilient. Years later, the design still serves many thousands of users and continues to grow.

Your staff requires this level of agility to be effective in modern IT. Perhaps a problem needs a rapid response. Or perhaps your customers are requesting a new service. In a competitive world, you must be able to deliver quickly or a competitor will.

Agility Shortens the Path from Ideation to Impact

Agility is the power to think swiftly and move quickly. Reduce the time from conceiving an idea to testing that idea in front of its beneficiaries. Remove barriers to action while driving the cost of missteps toward zero.

In my previous example, we had a key advantage. We had strong separation of concerns, which simply means we could make a mistake in this one application without harming other parts of the business. We could innovate within our sandbox without putting other systems at risk of exposing unrelated data. As such, we were not inhibited by legacy processes intended to prevent risks that might or might not pertain to our situation. I estimate that we achieved in 3 days what might previously have taken 3 months.

Traditional IT Hinders Agility

Are your innovators telling you in one way or another that they feel stifled? If so, you and I aren’t the only ones who have felt this way. If you ask Forrester Research, they’ll tell you, “Legacy systems and bureaucratic structures hinder the ability to iterate and experiment rapidly.” Within Legacy IT, the approvals, tickets and logistics create a high barrier to pushing through a new idea.

When I see this, in the cloud or on-premises, it usually comes down to several factors. The cloud providers will tell you that reduction in capital expenditures — the up-front money required to buy new equipment —is a key enabler. There’s also the simple mechanics of ordering that equipment, waiting weeks for it to arrive, and then installing that equipment. But those expensive and time-consuming processes drive an even more burdensome problem. They necessitate business processes to control the excess time and money being spent. These business processes are designed to manage risk, but they're always going to create speed bumps for innovation-fueling agility

Preventing Chaos

Those old business processes weren’t created without reason. Without good governance, the portfolio can devolve into chaos.

When decisions have long-term or irreversible consequences, plans must be built in detail over a long horizon with documented, albeit untested, assumptions. Without experimentation, those assumptions cannot be tested until much time and money has been expended. Embracing experimentation means replacing those untested assumptions with observed facts. In my example, if serverless did not work as hoped, we could have fallen back to a more traditional approach.

A cloud-first strategy avoids the initial capital outlay for ideas that may fail or require refinement. If the idea fails, turn it all off and spend no more. If the idea needs refinement, swap out the old services for new services and continue experimenting. This kind of streamlining and control are key to avoiding the chaos that can come with experimentation without the cloud.

The Right Controls for the Right Risks

On-premises or in the cloud, preventive controls must enforce standards, mitigate risks, and bound costs. This governance must match the technologies involved, and that’s where many organizations create barriers to innovation.

But applying old business processes to new technology commits two mistakes. First, the old controls encumber new projects with rules designed to prevent risks inherent to the old technology. This destroys agility. Second, the old rules ignore the new risks that arrived with the new technology.

In my experience I see three areas where this happens often. Each is worth its own article but I'll summarize them here.

Security Controls. On-premises infrastructure can be built to isolate workloads. Cloud provides this by default. By maximizing separation of concerns, your decisions affect your workload alone, reducing the need to coordinate with unrelated teams. With proper standards enforced by guardrails and monitored through configuration management APIs, a team can act independently and quickly within enforced limits.

Financial Operations. When on-premises or in the cloud, new projects must estimate their operating costs before approval. Developers estimate their needs and then add a guard band for growth and for estimation error. When on-premises, this money is spent up front. With cloud, the system can better match actual utilization, but the risk of excess spending is real. As Boston Consulting Group notes, a strong Financial Operations or “FinOps” practice is essential to aligning business, technology, and finance around strategic goals and business value.

DevOps Autonomy. Back in 1968, Melvin Conway observed that information systems copy the structure of the organization that created them. A typical on-premises org chart might have separate teams for network, servers, firewalls, databases, etc. Each change requires a new ticket with resolution times set by service level agreements. Nothing happens immediately. In the cloud, these changes are defined by software templates. The workload’s devops team has the skills and authority to make those changes locally without submitting tickets to other groups. Interestingly, this, too obeys Conway’s law. Since the workload resides in its own box, the team organizes around that box.

Questions to Ask Yourself

● Does our current IT process embrace innovation and experimentation? Or does it place barriers to deploying innovations?

● Are cloud projects being held up by approval-based processes inherited from legacy projects? Or do teams have authority to make local decisions within budget and security guardrails?

● Do new projects target the cloud by default and organize around agility?

Innovation is key to serving your stakeholders inside and outside the organization. A cloud-first strategy serves this by removing upfront barriers, driving out irreversible decisions, and replacing untested assumptions with observable data. Achieving agility requires changes to business processes built for risks specific to previous technologies, but it crucially shortens the path from ideation to impact.

____

If you like this content, please connect with me on LinkedIn. And if you’d like to have a deeper discussion, send me a direct message and we can talk. If you have questions, we can answer them together.