A Better Metric for Analyzing the Value of the Cloud While you may be reading and hearing about

positive financial and the economic analyses regarding the benefits of Cloud computing, those analyses are based on unrealistic total cost of ownership (TCO), return on investment (ROI) and misinterpreted CapEx/OpEx calculations. Indeed, these calculations are missing a complete understanding for the value of the Cloud in the IT service delivery equation, which is why comparing Cloud computing alternatives requires a modern metric that fully understands the service delivery model. In my opinion, no two metrics were more injurious to the IT field than TCO and ROI. I have yet to meet one senior executive with budgetary responsibility that has accurately tied investment in IT back to a sizable gain or to represent a true TCO. Lets face it; these are notional concepts at best that were devised to be manipulated to provide IT executives with justifications for funding projects of questionable value to the business. Before you inundate me with nonsensical comments about investments by the likes of Amazon, Dell and Google, please note, IT is an expense line item for these companies; it is their business models and processes that delivered the profitability that ensued. Indeed, I would go so far as to assert that if you track a specific IT investment, directly acquired to support a singular initiative, for one year forward you may be able to show a positive return relative to that expenditure. However, if you track that investment over next three years, most likely you either have a break-even scenario or a loss. The reason I assert you will end up with break-even or a loss is because if you start to accurately identify the additional expenditures necessary to maintain and operate that investment, then costs start to dramatically increase relative to this single expenditure. To offset these costs, a business would need on the order of a 25% costs reduction or increase in profits to have a return. As I noted above, TCO and ROI are notional concepts designed to be manipulated by those with budgets to justify expenditures. I have yet to see one CIO actually go back and reconcile the initial ROI estimates against the original assertion past year one. This brings me to the point of this article. Interestingly, its IT that loses in the long run using these metrics because ,traditionally, these financial justifications have worked against them resulting in missed expectations. If you dont believe me, compare the turnover of CIOs to CEOs or CFOs in the business world. Now, with Cloud computing on the tongues of every executive who can pick up a copy of Forbes or Time, its critical for IT executives to ensure they select an appropriate metric that allows them to illustrate and accurately calculate value for investment dollars; especially in a down economy. Total Service Cost (TSC) The metric I recommend is total service cost (TSC). Basically stated as a formula, TSC is: (Cost of Infrastructure + Cost of Operations + Cost of Software + Cost of Risk) Billed Usage = TSC Cost of Infrastructure: Whether youre considering public, private or hybrid Cloud solutions, there is a computable cost associated with the infrastructure. Of course, computing this for

private Cloud configurations can be more difficult, especially if you have not established effective metering solutions. That is, without effective metering solutions, an accurate TSC requires that you allocate and track percentages of the overall costs for the used infrastructure, inclusive of utilities, network, storage, etc. across services. Additionally, while it would be simpler to estimate, the problem with estimates is that it will impact your ability to accurately determine costs for underutilized infrastructure; a key component in deciphering Cloud alternatives. Cost of Operations: These costs must include all resources involved with delivery of a service including management of the information, such as information quality and assurance, in addition to traditional network, systems and data center operations. This is one area where service oriented architecture (SOA) is an important design paradigm for Cloud computing. Those who recognized the strategic value of SOA to specify and manage services will really see simplification in computing operational costs on a service-basis over those that have delegated SOA to being a technical effort focused on Web services and ESBs Ultimately, SOA is a fractal pattern. Services are made up of other services. Packaging and costing those services simplifies the overall costing models for aggregate service; in this case help desk, monitoring, system administration, etc. By packaging and costing each of the operational services appropriately, you can amortize the cost of the operational services across all the composite services that are dependent upon them. Cost of Software: Calculating this metric is can be dependent upon how you have calculated your cost of operations. If you included the costs of help desk software and network monitoring software, accordingly, in your operational service cost, then you wont be allocating here. However, if you choose to focus operational costs solely on non-technological resources and allocate all software costs in this bucket, then you will need to track the allocation of a percentage of all software used to deliver a particular service to the TSC. It will probably simplify your life if you go with the former approach over the latter since it will be a burden to track the entire software dependency tree for all services you deliver. In this case, the only software costs you will be required to track is new and renewal of licenses, training, etc. for software costs directly related to the delivery of a service not captured in the delivery of any other service. Note the value of service boundary modeling in this equation. If it turns out that two services should rely on the same software, then you have the option of building and packaging a service around that software and centralizing the costs for it there instead of attempting to manage discrete allocations. Also note that we are describing the packaging and delivery of the software as a servicethis is focused on the usage, SLA and meteringnot delivering software servicessoftware with an exposed API. Cost of Risk: Now that you are delivering an economically measurable entitythe service you can assume that theres a cost associated with that service being down, breached or exposed. While you can avoid including this cost in your projection for your TSC, if it should occur, then your overall costs for delivering the service could skyrocket. This is a bit like letting it ride on black on the roulette wheel. As long as you dont hit red, youre ahead, but one red can wipe out all your gains. Certainly risk projections can have a significant impact on your TSC, but

over time, the accuracy of your TSC will become respected by the business as a reliable metric they can count on to run the business. Billed Usage: Through billing we get to focus on the expected value of all of the above costs to the business. Determining an appropriate unit of billing may require the assistance of others outside of IT, like marketing, sales and accounting, which is a great opportunity to socialize what IT is doing with the business in a way that is inclusive of their input, but not specific to their needs (which means theyre working with you not looking at you as a hurdle). Obviously, your unit of billing should be relative to the overall value of the service and incorporate the aforementioned costs. For some, this billing may be accounted for through a chargeback mechanism, or as some like to note funny money, but the importance of having billed usage as a metric should not be undervalued. For one, say your company wanted to acquire this capability from an outside service provider, this metric would allow executives to compare the costs of providing it internally over acquiring it externally. Additionally, this metric will tell you if your service is being valued and used by the business. If youre running a service in the red, then you should re-think the purpose and approach for delivery of this service. Heres quick example that illustrates that even if you outsource all the above costs, the TSC will give you an accurate picture of what it cost to deliver the service and help you determine in a normalized way the optimal Cloud solution for your organization. If you acquire your infrastructure through a public Cloud provider you have a fixed cost per unit of CPU, storage and memory, but, you still need to accurately estimate your usage over a time period, such as a year, to get a clear picture of your TSC. This can be trickier than you think since public Clouds are subject to unintended usage, such as hackers and denial-of-service attacks, which can run up your costs inadvertently. Your costs of operations should include the salaries of any human resources required to monitor and operate the service, inclusive of technical support. Your Cloud provider may offer this for an additional monthly cost or you can outsource this need for a fixed monthly fee. You can also outsource the development and maintenance of your software to a firm in India, China or Eastern Europe, which leverages all open source projects and keeps your development costs relatively low. At this point, youve laid out very little capital to get started, your development costs were kept relatively low and youre service is being managed by your Cloud provider. This sounds resoundingly like the story many startups delivering Cloud-based services are prescribing as success. However, because you highly leveraged with a significant number of dependencies on external agencies, your cost of risk is significantly higher than if you has hosted it in a co-located facility with less compute capacity and used your own employees, which maintains knowledge internally to your company, which causes you to set a higher price point for your unit of billing, which results in slower uptake in sales. This example is not designed to deter Cloud adoption, but merely to illustrate that common CapEx/OpEx, TCO, or ROI calculations that have been expressed to date, at best, illustrate the immaturity of understanding of the costs associated with Cloud computing from the perspective of being a Cloud tenant. I propose that the TSC, with its SOA foundation, while rudimentary, is a more effective metric for costing and analyzing Cloud computing alternatives than what has been proposed to date.