By David Gross
Few metrics are as overused yet as useless as TCO. Largely developed by sales and marketing to close deals, it has very little connection to financial reality, because it ignores the time value of money, offers little support of any kind for a buy vs. build decision, and typically pulls in a lot of costs that you are going to incur anyway.
With data centers, TCO numbers can get comical, because this is an automated industry, where personnel costs are often a very small share of total outlays. And while vendors love to talk about how they save power, which can also reduce operating costs, many of the products that save power require higher up front capital outlays, providing weak financial returns. So then how are you supposed to measure data center costs? How are you supposed to decide between more power consumption or more capital outlays?
As I wrote last week, data center expenditures should be set to minimize the NPV of cash outlays within operational constraints. This is very different than randomly tagging your PDUs, CRACs, or servers with allocated overhead costs as TCO models typically do. Moreover, many of the financial decisions that take place involving a data center don't involve money, but time. If you're building your own facility, it's not really a decision to spend more or less, it's a decision to spend now. If you're renting additional space, you're not just deciding on how much to spend, but when. Moreover, TCO really doesn't apply, because you don't own anything, and if you force some sort of TCO calcuation, you need to place a discount rate on future rent payments, each of which occurs at a different point of time.
Specifically, here are some things the industry can do to bring TCO models closer to the financial reality:
1. Stop Summing Costs from Different Time Periods and then Comparing Them to One Another.
This is a common tactic, to claim half of the "expenses" are capital costs. Problem of course is that there is no such thing as a capital expense, there's depreciation of up front capital outlays.
Moreover, don't say 50% of your "expenses" are capital outlays, say 60% of the present value of your cash outlays are capital expenditures at a 7% discount rate, but this rises to 70% at 12%, which is your corporate cost of capital. If it costs more to borrow in the future, you'll need to look at renting more. This is just one way in which financial data can be used to support important decisions, instead of just validating some vendor marketing department's claim about savings.
2. Stop Making Pie Charts with Cost Categories
Just about every aspect of a data center operation can be rented or bought. A key decision factor then isn't whether power is 15% of costs or 20%, but the fixed cost of turning a rented item into an owned one. In the case of the facility, this is obviously going to be very high, in the case of a blade server, it will be low. This ability-to-buy is far more important than assigning a percentage to facility rent or blade servers because you need both a building and servers regardless of what you decide financially. What matters is if your cash outlays are higher than peers or competitors because you're leasing when you should be buying, or building when you should be renting.
3. Constantly Monitor the Tradeoffs You've Made
TCO often does a poor job of determining trade-offs that underlie decision making. For example, if you buy a power hungry, 9 watts per Gbps Ethernet switch because it has a low port price, you need to monitor prices for power, prices for higher line rate ports, alternate protocols, alternate topologies, in addition to your corporate cost of capital.. The cost justification for such a tradeoff could change, and it won't show up in any static TCO spreadsheet.
Ultimately, as time passes, corporations will be spending more on renting, building out, and operating data centers. Those that move beyond TCO models stand to gain significant financial benefits over those who try to force numbers into convenient categories that have little to do with financial reality.