Agility Part 2 — The Evolution of Value in the Private Cloud

Agility Part 2 — The Evolution of Value in the Private Cloud

When an IT project is commissioned it can be backed by a number of different statements such as:

  • “It will reduce our TCO”
  • “This is a strategic initiative”
  • “The ROI is compelling”
  • “There’s funds in the budget”
  • “Our competitors are doing it”

Some of these are better reasons than others, but here’s a question.  Imagine a project where you could improve your infrastructure and allow your organization to become more agile.   But without a specific business performance improvement or TCO to link to it, which of the above statements would allow you to move ahead with the project?  We may need a new model for value creation in IT if we are going to get transformative projects and not merely tactical solutions approved.

TCO is a measure which attempts to measure IT costs within the enterprise, while ROI can attempt to look at IT as an investment (at least those elements which are tangible).  To borrow an investment term, what is the NPV (Net Present Value) of your IT assets? The value of an IT asset ultimately depends on how it is used.  Just as human resources can become inefficient in a poorly modeled organization, IT resources can similarly be inefficiently utilized if not modeled on a vision of agility and value.

What’s the value of being able to deploy a new application in 1 months versus 3 months? What’s the value of our IT staff getting twice as many projects completed in a year’s time?  What’s your RoIT (Return on IT)?  As we explored in Part One, Agility creates value by allowing the business to execute their business strategy in less time.

While I want to explore valuation methods further in a future post, lets take a look at how value can evolve as IT adopts the private or hybrid cloud model.  Before we get into details about how various private cloud stacks (Vblock, FlexPod, etc.) can add value, I thought it would be helpful to “set the table” and construct a value model that can be referenced in future posts in this series:

The centerpiece of the graphic above is the inverted triangle – as organizations further evolve upwards towards the private cloud/IaaS model, there is more and more business value to be captured; first in the forms of CAPEX and OPEX, and then ultimately in the form of Agility. Let’s take a step back and look at each of the three elements within this triangle.


CAPEX is CFO shorthand for capital expense. In IT capital expense would normally consist of things like datacenter space, and server hardware (with electricity and cooling being related variable costs). If you can run 30 web servers on a single physical server that’s a significant capital expense savings. Virtualization is certainly a “green technology” as in previous posts I noted the savings that have been realized by many (and promoted by utilities) in electricity costs. CAPEX reduction is the original value proposition of virtualization (do more with less hardware) and is probably the reason many may have adopted virtualization in the first place. The evolved IT organization will look well beyond just CAPEX benefits however….


OPEX is also CFO shorthand and refers to operational expenses. Perhaps the first example of OPEX benefits that many organizations discovered after deploying virtualization is provisioning. In the past IT may have installed an OS from CD (hours of labor) or they have invested time and/or money into a more automated method for building servers.  With virtualization you could now create a new VM with a few clicks and have it ready for consumption within just a few minutes – offering a big reduction in operational expense from what many IT organizations had previously.

Basically reducing OPEX is all about getting things done more efficiently – more automation, less steps, less labor, less effort and less time – and it’s incredibly important.   The full spectrum of opportunities for OPEX reduction is huge.  OPEX will span many disciplines and technologies (even organizational management) and include key elements such as automation, orchestration and more.  We will get into more specific examples of OPEX reductions in future posts.


Now the line between OPEX and Agility here is a bit…well, cloudy…and the line here isn’t going to be clearly defined.  The point here is that the IT organization has put itself into a position where it can be more nimble and respond more quickly.  Joe Weinman of HP recently published a whitepaper called “Time is Money:  The Value of ‘On-Demand'” in which he attempts to show how lost opportunity can be quantified. The graph above shows a red demand curve, with a green resources curve falling a bit short.  The difference between these two curves represents unserved demand and can actually be quantified (to the extend D and R can be).  Unserved Demand may represent lost customers for the service provider, or it could also represent the gap between what the business wants from IT and what IT can provide.  Taken a step further it may be even possible to determine how much market demand (and revenue) was lost to the business because IT was unable to provide the volume of resources that were desired when they were desired.  Joe concludes in his whitepaper:

We have seen that not only is there a time value of money, there is a money value of time, specifically, increased agility and responsiveness lead to reduced loss, including a reduction in missed opportunities. Time is money.

This is exactly why I believe that Agility ultimately has the potential to provides more value than just OPEX alone.  Reducing OPEX is generally a TCO play on the cost center model but it can also be a building block towards Agility.  Agility is the ability to quickly deploy infrastructure as needed to satisfy business demand and when you can do this you are evolving away from the IT-as-a-cost-center model and towards IT being a revenue generator and business parter which can successfully execute the organization’s business strategy.  That’s profound.

Let’s Add Some Clarity

Now that the value model has been introduced we should probably go into a bit more detail on several things including:

  • Is virtualization a requirement for cloud computing?
  • Abstraction, APIs and OPEX
  • Has your datacenter evolved beyond a cost center?

Virtualization and Cloud Computing

First of all we should take a moment to define our terms.  Too often the word “cloud” is used in way too many different ways and has become sort of general marketing term as of late.  What we are really talking about here is Infrastucture as a Service (IaaS) which usually refers to a private cloud scenario (it can also refer to the infrastrucure used to serve up Software as a Service (Saas) and public cloud applications).

Virtualization may not be a de facto requirement for “cloud computing” but in my view it is an essential part of IaaS.  The current Wikipedia entry for cloud computing says that IaaS “delivers computer infrastructure – typically a platform virtualization environment – as a service”.  Thus when you look at CAPEX in the value triangle, the implicit assumption is that virtualization has been adopted — you need virtualization to get to CAPEX and above.

Many companies however have not yet virtualized their mission-critical applications for various reasons (this is sometimes called VM Stall). But the technical barriers have been continually getting lower, as I most recently noted here in an article about Oracle RAC on vSphere. And even if there aren’t any CAPEX benefits for an application that requires a 1-to-1 consolidation rate, many companies will want to virtualize many of these workloads because of the OPEX and Agility benefits that become available when virtualized.

APIs in the Stack:

Virtualization As a Management and Abstraction Layer

Nicholas Weaver recently demonstrated with his excellent XBOX Kinect “Fistful of Cloud” demo (my post here) how the abstraction provided by virtualization also becomes a management layer that enables a whole new level of possibilities.  Today we can change the power state of hundreds of servers by pushing a single button, move VM’s across different servers, and even failover entire datacenters with a push of the button.  Virtualization provides not only flexibility-enabling abstraction but a management layer which can be utilized in countless ways.

Already today we have API’s in the stack for storage (VAAI), data protection (VADP) and security (vShield) with more APIs and enhancements to come.  VAAI already provides a bridge between the storage array and the hypervisor and perhaps we will soon see security APIs transcend to the networking hardware as well.  A well integrated virtualization stack can provide many more opportunities to reduce our OPEX costs (both time and money) by abstracting our workloads from the boundaries and limitations of yesterday’s physical non-virtualized environments.  I have no doubt that in an undisclosed bunker somewhere these APIs and new ones are being enhanced and created right this minute to enable more and more possibilities to manage and automate our abstracted workloads (VMs).  As EMC COO Howard Elias noted in a Forbes interview:

You have a virtualized infrastructure, you’ve virtualized your business applications, and now you add a management and security model and automation and orchestration where you truly have automated, policy-based, flexible management of your IT infrastructure. That’s where you really get cloud-like operations in a private cloud and even in a public cloud.

Evolving Beyond IT as a Cost Center towards Agility

I’ve actually seen some environments where IT management wanted to adopt virtualization so that they could tell others that they were using it.  Others saw the original value proposition of virtualization but haven’t taken steps to capture the additional OPEX and Agility benefits that are available.

CIOs and IT managers should take an introspective look at their environments and goals and think about whether they want to continue using the IT as a cost center model, or evolve towards the IaaS/Private Cloud model in order to empower the business with Agility.  Chances are your competitors are in varying stages of implementing private cloud concepts.  All things being equal, the business that can execute their business strategy the quickest will win in the marketplace.  Organizations which are not actively moving towards Agility risk being left behind and being unable to quickly and efficiently execute on what the business asks of them.

What’s Next?

Now with this value model established we will be looking at more specific and details ways in which stacks, converged infrastructure and automation tools in future posts such as:

  • Obstacles To Agility
  • vCloud Director
  • The” x86 Mainframe”
  • Orchestration
  • and more….

Agility Part 3 will focus on traditional obstacles to Agility while future posts will show go into detail of specific solutions that can overcome and transcend these obstacles.

4 Responses to Agility Part 2 — The Evolution of Value in the Private Cloud