Cloud Computing Economics - There Is No Free Service

Cloudonomics Journal

Subscribe to Cloudonomics Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Cloudonomics Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Cloudonomics Authors: Lori MacVittie, Skytap Blog, David H Deans, Shelly Palmer, Tim Crawford

Related Topics: Cloud Computing, Cloudonomics Journal, Microservices Journal, Cloud Data Analytics

Cloud Computing: Article

ROI: Justifying the Cloud

You can improve TCO by up to 80% by using applications in a public cloud

A classic use of ROI or its twin TCO is in the Microsoft Economics of the Cloud, Nov 2010 paper. The conclusion is you can improve TCO by up to 80% by using applications in public cloud versus on-premise deployment. The basics of the calculation being:

  • improved utilization (10% to 90%) enabled by virtualization/consolidation & elasticity
  • the economies (power, operations, HW purchase etc..) of scale of multi-tenant cloud scale hosting

Given most costs in a DC are directly linked to the amount of infrastructure deployed, then improving utilization from 10% to 90% sounds like the primary justification for the 80% improvement. The misuse of the information is not more evident that when Phil Wainewright writes that the strength of this "research" is enough to put the nail in the coffin of the concept of private cloud. Definitive words indeed.. The problem I have with this conclusion is it is a black & white, monolithic view of "what is cloud". This is combined with TCO/ROI modeling that uses some pretty broad assumptions to underpin the cost model. It is often good marketing or publicity to offer polarized view of the issues, but it does not provide a real-world executable decision making capability (read "value") for future consumer of cloud services (public or private). So why are people needing to kill the concept of the "private cloud"? James Urquhart tweeted it best (4/12/2011):

  • "I don't hear ANYONE who isn't a public cloud provider or SI who bet the farm on public cloud make any claims about "false clouds". Period."
  • "Oh, wait. There may be one or two startups and journalists in there...all of which stand to gain from public cloud. Sorry about that. :\ "

If you take that approach and as a result just build a "cloud" for the sake of "cloud" then you are making "the BIG mistake". Implementing a framework as a product is doomed to fail. If you implemented SOA this way then disaster, ITIL would equal chaos, Prince2 would create inertia, Web2.0 would have resulted in mega-$$$. These concepts, whether they be architectural, process or other are meant to guide execution, not be implemented blindly. So how should ROI be used? So when people ask the question. "What's is the ROI of the cloud?" it is not an issue of "What is an ROI?" or "What is the benefit of Cloud?" or even "What data goes into a ROI calculation?". It is about how to answer the question of why, what and how to adopt the cloud. Most of the Cloud ROI (return-on-investment) or TCO (total cost of ownership) discussions are like the whitepaper from Microsoft. Comparing side by side a complex cloud deployment with a traditional infrastructure deployment. In reality, it's too difficult to develop a model to cater "true total cost of ownership", you quickly have to jump to broad assumptions, and narrow scope to make it manageable. If you start you model as a greenfield cloud deployment, your model has radical inaccuracies as you try apply this to brownfield or legacy enterprises. Try starting based on data of a legacy deployment and you have huge problems dealing with the depreciation of assets. Brownfield models also have the challenge of dealing with the elasticity of the delivery assets or opportunity costs; for example, you can manage 100 or 150 servers with the same team, or your existing 20% utilized asset can possible only support 2X or maybe as much as 10X the workload. You then overlay this with the changing economics of real estate facilities, HVAC, compute. The result is, you end up with a model that can have error factors upward of 100% It's too complex a problem to solve without a huge dataset to validate the variables, dependencies, etc... Armada takes a Fast Track approach to solving the problem. You are looking at cloud as a reference framework to help develop a solution that returns the business value. You calculate ROI based on a specific situation and end-state solution. A ROI needs to have a pay back of less than a year, so long-term theoretical modeling has no significant value. So how do you do it? Remember three things;

  • You must have a triggering event
  • Use scenario analysis and not lifecycle modeling
  • Apply the 80/20 rule to data, and only the stuff that impacts your costs

Triggering Event
Most of the time being a technical architect in consulting creates looks of skepticism from engineers in enterprise customers. Fair enough, when I was in that seat I felt the same way. When I gave up internal politics for politics of "revenue/pipeline", "everyone is a salesperson" and "whitepapers and webinars" a few things became pretty crystal clear. The most important thing is, don't waste time doing anything unless there is a pain point, problem to solve, triggering event. Wants are good, but needs are better. This is important in ROI calculation. The triggering event is the anchor point for the evaluation and defines where you are looking for the biggest "return" in the ROI.. The triggering event can be something specific like;

  • "we will run out of datacenter space in 6 months"
  • "it takes us 6 months to deploy an environment"
  • "we are on CNN if our primary datacenter fails because we have no DR"

Alternatively, it can be softer and described as the business goal, business driver like:

  • "we need to reduce operational management costs"
  • "we need to improve our infrastructure utilization"

These things are scoping statements for the project and then the ROI is applied to the return for this project.

Scenario Analysis
You scope the project, but if you try and calculate the return based on lifecycle costs over a long term, you will be scratching your head forever. If the ROI is not 1-3 years, then you are probably not doing it. Most likely it needs to be in less than a year. Scenario analysis is fairly simple, but a little time consuming. It is, however, a step down the direction of implementation, rather than a detour into developing a business case that will never be used or validated later. You create three (3) scenarios:

  • Business as usual - sometimes this is the "no decision, decision" or just solve the problem the way you have in the past
  • Option 1 - the "go big or go home" scenario, build the pure play cloud solution
  • Option 2 - the "pragmatic solution", or sometimes called the cheap solution. This is often the winner, but generally can be folded into option 1 after a subsequent round of funding.

Gather the requirements. Design the end-state architectures for three options and price out the implementation and on-going costs. You are already starting the design, so when the solution is green lighted, you are ready to go..

80/20 Rule of Data
A basic premise of the Fast Track method is to make decisions based on readily available information. Creating data and model takes time and effort for little return. In the time it takes to do this, IT services are evolving and changing. So in collecting data for a ROI analysis, use what is available, don't over process it and limit yourself to the data that impacts your business. From Gartner and other models we know that the biggest contributors to ROI/TCO are;

  • Hardware Costs (storage, compute, network)
  • Hardware Maintenance/Support
  • Software License (applications licenses, tools licenses etc..)
  • Software Maintenance/Support
  • Management & Operations (people, benefits etc..)
  • Facilities (real estate, hvac, security etc..)
  • Development/Customization/System Integration
  • Opportunity Cost (increase costs in existing infrastructure by reducing its scale)

Focus on capturing this information to support the scope of your project. If your project is not looking for value in reduction of power costs, then don't include it in the model. Just deliver the value you have visbility and control over. You should try and be as complete as possible, without creating an environment of political inertia. So with this approach its easy to capture a return on investment (ROI) calculation. I need to add, that David Linthicum wrote a very relevant post that reinforced that ROI does not make a business case. You need to also include the soft value factors, which for the cloud revolve around agility and time-to-market. Hard to define or place a value, but critical to the final assessment.

More Stories By Brad Vaughan

Brad Vaughan is a twenty year veteran consultant working with companies around the globe to transform technology infrastructure to deliver enhanced business services.