Cloud Computing: Two Kinds of Agility

CIO — A key benefit often discussed about cloud computing is how it enables agility. This benefit is real and powerful. However, the term agility is used to describe two different kinds of benefit; both are real, but one of them will, ultimately, be seen as offering the greatest impact. This post will discuss the two types of agility and provide some examples of how compelling the second type is.

What does cloud agility mean? It's tied to the rapid provisioning of computer resources. Cloud environments can usually provide new compute instances or storage in minutes, a far cry from the very common weeks (or months, in some organizations) the same provisioning process can take in typical IT shops.

As one could imagine, the dramatic shortening of the provisioning timeframe enables work to commence much more quickly. No more submitting a request for computing resources and then anxiously watching e-mail for a fulfillment response. As agility may be defined as "the power of moving quickly and easily; nimbleness" it's easy to see how this rapid provisioning is referred to advancing agility.

But here is where the definition gets a bit muddled. People conflate two different things under the term agility: engineering resource availability, and business response to changing conditions or opportunity.

Both types of agility are useful, but the latter type will ultimately prove to be the more compelling and will come to be seen as the real agility associated with cloud computing.

The problem with delivering compute resources to engineers more quickly is it is a local optimization — it makes a portion of internal IT processes more agile, but doesn't necessarily shorten the overall application supply chain, which stretches from initial prototype to production rollout.

In fact, it's all too common for cloud agility to enable developers and QA to get started on their work more quickly, but for the overall delivery time to remain completely unchanged, stretched by slow handover to operations, extended shakedown time in the new production environment, and poor coordination with release to the business units.

Moreover, if cloud computing comes to be seen as an internal IT optimization with little effect on how quickly compute capability rolls out into mainline business processes, the potential exists for IT to never receive the business unit support it requires to fund the shift to cloud computing. It may be that cloud computing will end up like virtualization, which in many organizations is stuck at 20 percent or 30 percent penetration, unable to garner the funding necessary to support wider implementation. If the move to cloud computing is presented as "helps our programmers program faster," necessary funding will probably never materialize.

Continue Reading