Steve Watkins, Guest Blogger
Steve Watkins is a Consulting Systems Engineer for Cisco Intelligent Automation for Cloud. He came to Cisco as part of the newScale acquisition in 2011. He has been helping customers manage the migration to IT as a Service (ITaaS) since 2004.
Showback and Chargeback have become increasingly hot topics for IT, especially infrastructure teams. This is fuelled at least in part by the general acceptance of cloud computing, including private clouds and SaaS applications. Chargeback (and even Showback) are great ways of affecting behavior of the consumers of IT. It keeps consumers from demanding an unreasonable amount of services, and encourages them to use of what has already been invested in. There is also a growing mandate from Finance to make IT accountable for its spend, or at the very least to justify any requests for further investment. So infrastructure teams find themselves in the unexpected position of defining prices for the services traditionally offered. Most have no idea where to start.
Several vendors have produced offerings to help manage the showback/chargeback business case. This post will not discuss any vendor in detail. Instead, I want to talk about philosophy.
Broadly speaking, there are two major approaches to creating a price model for IT. There is the Utility-based model, in which pricing derived from actual consumption of CPU cycles, RAM, bandwidth, storage, etc. In this model, if you stood up a virtual machine for one week you would only pay for the actual amount CPU cycles and storage you consumed.
Alternately, there is Service-based pricing, which advocates a fixed price based on either the service itself or some other unit of measure such as hours, etc. In this model, if you stood up a virtual machine for one week you would pay for how many hours the VM was active, whether you used it or not.
I always council my customers to adopt service-based pricing. I think utility-based pricing is the wrong approach for IT departments, especially infrastructure teams. Here are my reasons:
1.INFLEXIBLE – Utility pricing is asset based, and therefore assumes that the assets will remain more-or-less the same. The model breaks down when you introduce changes, like renting infrastructure from public providers or changing service levels. What about if I offer VDI next year? That may mean two different types of pricing models, which gets even more complex. A service-based pricing scheme works with all services.
2.POOR CAPACITY MANAGEMENT – by only charging for the CPU cycles you actually consume, it encourages users to stand up systems and leave them in place.. which is exactly what we don’t want. Think of renting a car: you rent a car for 4 days but only drive it for a total of 3 hours, you still have to pay for all for days. If I just paid when I actually drove it, I would keep it all the time. We want to encourage users to return unused assets. Which leads to..
3.FINANCIALLY INACCURATE – the appeal of utility pricing is that is seems to offer the ability to recover asset costs. Actually figuring out what to charge and what a service is truly costing is a black art and is very, very difficult. In other words, charging by the CPU cycle is not really helping you financially account for assets. For one thing, it pretty much ignores overhead like salaries, managers, utilities, etc. So the main appeal turns out to be fallacious.
4.NEEDLESSLY COMPLEX – there is a fair amount of work and complexity in tracking utility consumption. But in reality, there is not very much gain. It is much simpler to adopt a service-based fixed rate and you get the same result. Showback and Chargeback inform user behavior no matter how it is calculated. Why add all the complexity here when you could use that energy, time, and consulting dollars for extending functionality or offering different service levels.
5.IGNORES ADD ON SERVICES – this approach essentially treats the service as a commodity, when actually the service should be considered premium or at least have different service levels. For example, there is patch management, back-up frequency, network QoS, access or ACL rules, etc. How about offering DRaaS? The quality of service provided by most IT shops is quantum leaps above EC2, but not all consumers understand that. This is also part of the transition to ITaaS. Offering different service levels at different prices. It my not be the way your IT dept is going today but it will be where they need to be tomorrow.
6.POOR CUSTOMER ALIGNMENT – it is very difficult for a project manager or consumer to know in advance what their CPU usage, bandwidth, etc. will be. That makes it very difficult to estimate what the service will cost them in advance. Imagine dropping your car at a mechanic and having them fix it without knowing in advance what they will fix and how much it will cost. What consumers do know is the configuration desired and maybe even how long they will need it for. With service based pricing your customer can know what it will likely cost him in advance and can make rational decisions e.g. Linux VM with Apache server@ $1.75 per day X 30 days = $52.50 from my budget.
In summary, service-based pricing is simpler, more flexible, and aligns better with the business. It is also a key component in transitioning from an asset driven IT shop to IT as a Service.