“Total Cost of Ownership” models date back to the early 1990s. They are a useful tool to compare stacks (hardware + operating system + middleware + packages + skill demand) when making choices between deploying one or another of these.
As enterprise architects, what matters, though, is not the “industry” TCO projection, but your own enterprise total cost to own and operate (TCOO).
As consumers, for instance, we’re all aware (whether we do anything with the information or not) that an older personal computer may well provide useful services for four or five more years if a Linux distribution is loaded to it in place of the Mac OS or Windows system it used to run. We probably don’t act on this because we don’t need “another computer” — what we need is a replacement one, because we only use one.
Head into the enterprise, though, and there is a demand for many computers. The possibility to make use of this information suddenly comes into play. That, in turn, this applies to mid-range and mainframe computers being repurposed just as much as servers in the rack makes no difference. Changing the nature of the stack, to keep a fully paid up asset, is potentially very good for business.
This is why getting to low cost has nothing to do with which vendor offers the best stack, and everything to do with running the ones that lower your curve over time.
I said “curve”, because for every element there is a curve in play. There are workload sizes which stop making sense — either too small (you’re expending resources [heating and cooling, power, etc., and retaining people time to service the asset] with little to no return worthy of the name), or too big (out of capacity, or asking a component to do too much).
The elements in the stack, which include the environmental costs, the people costs, the cost of skills in the marketplace based on how densely they’re used in your market, the depreciation left on the components, their maintenance charges, plus the components themselves, are all part of drawing a TCOO curve for your configurations. That’s not an industry average: that’s your unique profile — and your goal should be to get as much of your workload as you can to the sweet spots at the bottom of the U-shaped TCOO curves as you can. The middle ground (enough work, but not overloaded) is where the low cost range resides.
You can, of course, have too much diversity by trying to optimize each individual element. Your goal is to optimize reasonable wholes, not individual parts. By doing so, you are able to shift work around and thus capture price-performance improvements as this piece here, that piece there, gets replaced.
Going forward, IT will be less about technologies, and more about financials. This sort of TCOO-based technology roadmapping is an excellent start to making that transition, unlocking hidden value in your configurations (and, if it matters to you, outperforming most outsourcers at their own game).