Calculating Cloud ROI, Part 1
Once you've have identified the actual unit of deployment, you should consider what components make up a fully loaded cost. If your IT team includes an IT financial analyst, you are fortunate. If not, you may need to make friends with someone in Finance to get help and support in gaining a practical understanding of the components of a fully loaded cost.
02/05/11 5:00 AM PT
As IT attempts to separate hype from reality, finding the real ROI in cloud adoption can prove elusive. Nonetheless, a demonstrable ROI must be developed as the basis and justification of a cloud transition plan.
In this article, I will examine a method of valuing IT resources to build a case for cloud ROI. I will also dive into some related issues and concerns surrounding the cloud.
Defining the Common-Sense Cloud
While there are as many definitions of "cloud" as there are vendors selling cloud infrastructure, let's pause a moment and consider the following common-sense definition: "Cloud" is an overarching deployment architecture/strategy that uses virtualization, automation and governance to rapidly deliver (and reclaim) information technology services designed to meet specific business needs at a specific per unit cost.
Typical implementations of this model depend on highly flexible resource pools. The cloud strategy provides on-demand services from a virtualized environment, making the underlying technology transparent to the consumer.
Services in the cloud model include Software as a Service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). Cloud services may be provided by internal or external service providers, or both. The internal cloud provider will typically have implemented the ITIL service provider model and will utilize automation to quickly deploy resources as services from a virtualized pool on a pay-per-use basis.
Understanding Current-State Costs
It is trite but true: To understand return on investment (ROI), we need to understand current-state costs and compare them to future-state costs. This applies whether we are looking at SaaS, PaaS, or the more common (internally supplied) cloud functionality of IaaS.
While many IT organizations understand their budget and have detailed projections behind budget requests, very few have a clear handle on the unit cost of deployable services. Overall costs may be generally well understood, but few organizations can specifically identify the fully loaded cost of the unit allocated or deployed to the consumer.
In the most common cloud transition strategies, we find a general trend to outsource SaaS and PaaS while often insourcing IaaS, possibly the latter is driven by concerns with security. Regardless of which type of cloud is being considered, and regardless of whether it is internally or externally sourced, realistic ROI information requires us to first understand current cost under the existing infrastructure and then compare it to future cost under cloud deployment.
In the cloud model, services are supplied and priced on the resources consumed, typically over a time period. The cloud service provider, if external, will typically have clear pricing that covers the fully loaded cost of the consumed resources plus their margin.
The internal service provider must follow a similar model if only to ensure its operation is and remains cost-competitive. To understand the ROI of a cloud service, whether it is internally or externally sourced, it is essential to first understand pre-cloud current state costs in the same terms as the prices/costs presented by the cloud service provider.
This means IT must develop a method of identifying two key cost components 1) the fully loaded cost of a Gigabyte (GB) of consumer-usable storage; and 2) the fully loaded cost of a Gigahertz (GHz) of consumer-allocated computing power.
The determination of the current cost of resources intended for outsourcing to SaaS or PaaS is relatively simple, because we are typically dealing with readily identifiable and chunked infrastructure. The servers and storage involved in supporting software intended for outsourcing to SaaS tend to be readily identifiable and tend to reside on infrastructure that is not used for other purposes or is readily inventoried.
Resources intended for deployment as an internally provided IaaS cloud are more often shared resources and are often already virtualized to some extent. This complicates the identification of a comparable current vs. future cost calculation. However, before we progress down that path, let's pause to first identify what is meant by a fully loaded per unit cost.
Identifying a Fully Loaded Cost
Fully loaded unit cost indicates that we have first identified the unit of measure or the unit of deliverable resource and that we have then understood its true and total annual cost.
In the IaaS model, we need to understand the fully loaded cost of a "configured for use" GB of storage and GHz of compute power. The cost of a GB of raw storage may be multiplied many times to arrive at a "configured for use" GB cost.
Before storage can be utilized by an application, it should first be allocated to a tier of service with characteristics, including disk architecture through some form of RAID, then operational protection through additional storage utilized for backup, (multiplied by retention policies and divided by dedup/compression ratios), and finally the addition of disaster recovery protection GB, including replication GB and snapshot GB.
It is not unusual to find ratios of 10:1 to 50:1 for raw GB to "configured for use" GB. We conclude that it seems "a GB isn't a GB and a GHz isn't always a GHz."
The cost of a GHz of compute power can also be subject to a multiplier based on the levels of protection appropriate for the tier of service it supports. At high-end tiers, protection schemas can drive a ratio of 3:1 in compute power GHz to support high availability both locally and remotely for disaster protection.
For example, 1 GHz of available compute power can require an additional GHz of compute power for an active/active or an active/passive configuration, and an additional GHz for a geo-clustered remote capability.
Now that we have identified the actual unit of deployment, we should consider what components make up a fully loaded cost. If your IT team includes an IT financial analyst, you are fortunate. If not, you may need to make friends with someone in Finance to get help and support in gaining a practical understanding of the components of a fully loaded cost.
First, there are the rather obvious purchase/lease expenses, with this cost being spread over the active life or the financial life of the hardware or software. Then, there are the ongoing maintenance costs for hardware and software. Next, you must find a way to get an average cost of IT administration duly loaded with management costs. To do this, you will need to gain an understanding of what resources, or percentage of these resources, are consumed in the administration of the storage and compute platform being studied.
Next, you should gain an understanding of network "per port" costs by capturing the network hardware and software costs, line costs, etc., along with maintenance costs and IT administration. Finally, you need a per square foot cost for facilities that includes floor space, power and air conditioning.
Spreadsheets are an ideal vehicle to model the costs and apply them at the deployable per unit entity. This process is most important, as these are the numbers that are going to drive your current-state costs and form the foundation of your ROI case. You want to be sure Finance is on your side and in agreement with your numbers (and assumptions, if any) before you make your case.
Continue reading: Calculating Cloud ROI, Part 2