Are still valid TCO studies?

mainframeitalia.com
Let me know
Published in
3 min readFeb 17, 2014

--

More than once I was involved in TCO studies. It was since the late 1990, when x86 virtualization was starting its real firts steps. Nowadays these kind of analysis are still used to demonstrate the goodness of a choice against others. But new doubts araise in my mind while delivering them and I whish to hear someone else opinions. I believe these doubts are the consequences of the changed IT pressure and my feeling is that TCO could became unuseful.

The TCO core is to show the evidence of economic impacts of a product/service acquisition choiche. This evidence cannot be so clear at acquisition time, but can be painfully discovered time after. So it is useful to see all costs/expenses to be sustainded for that product/service after the acquisition time. Often TCO elements are used as input for a more financial evaluation the ROI.

But if I would be a CIO, I would like to see a TCO with all, and only, my budget chapters. May be aside I would have a look to expenses not directly managed by me, but on which my company is focused. I remember that, showing TCO results to a railroad company, the CIO remarked the energy component saying "we are not interested in such king of savig, because we do not pay the energy. In our company the IT energy spending is less than 1/10000 related to train's energy spending, nobody care"!
Here is the first question: Nowadays how much of you are confident about which costs/expenses components are to be included? Time and sales pression often do not allow to define correctly this aspect and make us entering in the assumptions world. But further, how much of you start a TCO study asking these aspects to the stakeholder? It is a time effort activity, so it would be kind knowing how many CxO ask (and pay) for these kind of studies and how much IT companies provide them for free as a presale item delivering a sort of "best practices" TCO!

Another characteristics is the time. TCO have the assumption that evaluation targets, the objects to be acquired, do not change during the assumed period. But how much it is still valid now, that flexible Sw licenses and Cloud infrastructures can change them very quickly?

Of course the main goal of a TCO is an economic one. Now I do not want to open the debate if is better a CAPEX or an OPEX one, but new deploy models and the upcoming "Software Defined" architectures, do not make obsolete such kind of approach? My feeling is that the flexibility of economic aspects will make them more and more unseparable from performance impacts and non functional requirements. But forcing these aspects in a TCO imply to monetize them and it would be a very variable and arguable estimation, producing an unuseful TCO.

The last set of doubts is related to the target of TCO valutation. An enterprise is still requiring enterprise-wide systems and sustain related acquisition choiche efforts? Or, again, Cloud and emerging architectures, will reduce the choiches range only to software and services, making infrastructure a commodity? How much CIO are really moving in this direction?
In this article you can find an example. David Relly, the global technology infrastructure executive for Bank of America, describe theirs strategy with this question "Why can't companies fill their datacenters with white-box computers stuffed with x86 chips and a ton of memory, controlled by software that can make that box an in-memory storage device today, a software-defined switch tomorrow, and a server next week?" It will be nice to be updated about their ongonig works.

I am aware, this is not a withepaper, neither a post, but a set of thinking and questions about this topic written down in a waiting room. But I will be very happy to read here (or in LinkedIN groups) your opinions about them!

A better help will be to answer to these three answers.

--

--

mainframeitalia.com
Let me know

A place for mainframer and anti-mainframer started in Italian and now (almost) fluent also in English tweets are my own