The past few weeks we have been discussing some of the mistakes made in early cloud deployments. As a refresher, here are the issues we outlined:

1. Not understanding the business value
2. Assuming server virtualization is enough
3. Not understanding service dependencies
4. Leveraging traditional monitoring
5. Not understanding internal/external costs

This week we are discussing a key mistake that occurs fairly often; one that only manifests long after the solution is operational...blindly assuming that Cloud equals costs savings. Blasphemy, you say - how could it possibly not cost less? Let's take a look at the considerations and components of IT cost, and revisit this question at the end.

The unfortunate truth is that most enterprises have well-established IT cost allocation mechanisms, but few of these have any basis in actual consumption. Put simply, can you (or your users) confidently say that your IT bill reflects how much - or little - you use something? Traditional approaches to IT chargeback involve aggregating the net IT cost, and allocating it proportionally to business units based on head count, server count, or some other surrogate for allocating actual cost. This approach (sometimes affectionately referred to as ‘peanut butter' - you spread it around) has merit in its simplicity, but cannot be allowed to persist as we move toward Cloud operating models.

There may be some readers who don't have this issue - perhaps you are blessed with an accurate model, or lucky enough to be starting from scratch with no legacy IT systems. Congratulations - we're all jealous - go live long and prosper in the Cloud. But the other 99.9% should probably keep reading.

Delivering IT in a Cloud operating model - public or private - can absolutely be a powerful way to realize cost savings, but only if your organization understands exactly what the Cloud is replacing. When you move an application or service to the Cloud, can you confidently point to the person (labor), the server, the network, the UPS, and the CRAC unit that can be eliminated or reduced to offset the new cost of your Cloud service? If you can't answer that question, then the harsh reality is that your new Cloud service likely only increased your IT costs. Now you not only get an accurate usage-based bill for your Cloud service, through the miracle of ‘peanut butter' the costs for your remaining non-Cloud services just went up (fewer applications to spread the costs to).

Let's set aside the granular elements of IT total cost of ownership (TCO) for a minute and instead focus on the TCO differences between Cloud models. If you opt for a SaaS model, then you may be safe in assuming that most of the traditional IT responsibilities go away. You'll likely still need a modicum of IT support to monitor performance of the service and ensure any interfaces to your in-house systems are operational, but the rest goes away. Now let's contrast that to consuming an IaaS model...what functions are you, the accountable IT executive, no longer responsible for? Let's ask that from a different perspective: how many people in your organization today physically touch a server/storage device? In all likelihood very few, mostly the facilities team that's responsible for the rack and stack work. When you consume an IaaS you will still need some level of support from your server administrators, you'll still need an operations team armed with monitoring tools, and (if you like your job) you'll still need people planning and exercising disaster recovery and business continuity functions. And of course a PaaS model will fall somewhere in between. Still feel confident presenting your business case for Cloud adoption based on savings to the CFO?

Granular IT cost accounting is not fun (well, for most people anyway), but it is fast becoming a mandatory component for the IT environment of the future. Workload consumption metrics, harvested across multiple technology silos (network, server, storage) with robust metering tools are required. After all, if you don't understand how your applications and service workloads are consuming existing IT resources, then you won't know how to optimize when moving applications and services to the Cloud.