Monday, 21 September 2009

TCO - Time for an opensource framework?

So in my job I regularly see what each vendor claims to be a 'TCO model' - now funnily enough these normally show that the vendor's widget is much better than the competitor's other widget. Naturally each model has some elements in it that the others don't or places a certain weighting / emphasis on particular attributes that others don't.

Now this is a topic that is very close to my heart, as all standards and strategy changes I make in my company are supposed to be TCO based - with us not making any changes unless they improve own actual TCO. Naturally this breaks when vendors EOL products or TCO isn't the driver - but the principle is valid (although sadly a surprise to many people).

Now on @om_nick's blog here he reminded me that I had a draft blog on this, and that 'crowd-sourcing' such models can work quite well. There's plenty of good attributes listed so far on Nick's blog and I'm sure we'll all add many more as time goes on (I know I must have a good dozen or so TCO Excel models knocking around somewhere).

Of course I know that TCO isn't always the right measure, and that ROI or IRR can often be just as valid, but for lots of elements of infrastructure the first point of call is a TCO or CBA - and making those consistent would be a great starting point!

One thing I'm very sure about is that for each technology category there is more than one 'level' to measure a TCO at for different purposes, for example :-
Industry average TCO - ie what does a GB of data cost to store for x hours on average in the industry? (the analyst KPI - and product / vendor agnostic)

Estate average TCO - ie what does a GB of data cost to store for x hours in my company on average? (the CTO level KPI - and product / vendor agnostic)

Architecture average TCO - ie for this type of reference design (inc Function & NonFunctional Requirements) what does a GB of data cost to store for x hours in my company on average? (the architect level KPI) This is product / vendor agnostic and used for ROM costing and selection of an infrastructure architecture.

Category average TCO - ie for this class of product (eg modular storage, enterprise storage, small x86, medium unix etc) what does a GB of data cost to store for x hours in my company on average? (the catalogue level KPI) This is now technology 'class' specific, but still product / vendor agnostic, and is used for building up the ROM & architecture costs above.

Product TCO - ie for this specific vendor product & version what does a GB of data cost to store for x hours in my company on average? (the product level KPI) This is now product and vendor specific, and is used for selecting product within a category (ie direct product bake-offs).
There are many tricky parts in a TCO model, including :-
  • What to measure? (both what is desired, and what is actually possible over time)
  • How to measure?
  • Where to measure?
  • How frequently to measure?
  • What relative weighting to give?
  • What TCO output KPIs to give? (eg € per GB, GB per kW, € per IOP etc)
  • How to communicate such KPIs without creating dangerous context-less sound-bites for people to abuse (ie my absolute hatred of the phrase 'utilisation' - it's utterly meaningless without context!)
  • How to ensure transparency & clarity over assumptions and driving inputs?
  • How to value / compare functionality when no direct equivalents?
  • How to handle 'currently familiar' or 'keep same' (ie low cost of introduction) Vs 'new vendor & widget' (ie disruption & short term duplication of costs / disruption etc)?
  • How to handle 'usefulness'? (eg performance is a NFR than has value - does 'IOPS per GB per €' work?)
  • How to build a feedback loop and refinement model to periodically measure and validate TCO predictions Vs actuals, and take action accordingly?
  • How to protect confidential or sensitive values?
Getting a common list of assumptions, factors and attributes, relative weightings and of course values for all of these is the absolute key and a very valuable exercise for all - customer and vendor alike.

Lastly -
one company with a very interesting approach to TCO mngt is who provide a SaaS model for building & maintaining an automated TCO measurement and reporting platform - it's certainly sparked interest in my mind, would love to hear more about people's thoughts about or experiences with them.

Now I for one am more than up for spending time on creating an 'open source' TCO model that has many people's input and thoughts into it, that we can refine and revise over time and use to evaluate many vendor technologies - so what do other people think?


  1. Create your framework and release it no matter how unfinished of half baked it is. Then see if it's iterated by others and yourself.

    This is a product. Develop and ship it.

  2. ianhf,

    Good news: your model won't need to be very refined to be hugely valuable. Even a rough approximation (within 10 to 20% of eventual actual values) would do, judged by how little TCO actually ends up being a real decision factor in storage purchases.

    So I agree with Storagezilla (6p00d834519dbf69e2 for his friends): let's do the first open source Google Spreadsheet on this and invite comments. Then we can take it from there!

  3. Paul, I suspect the reason that TCO often is not a real decision factor is due to the fact that it's not understood!

    Ian's model however crude has got to be start in changing this! So completely agree with both of you; publish it Ian and lets start work on it.

  4. ok - so my thought process is that there is a model, and that model can then be utilised at the levels I indictaed above.

    As per the model, yes I will look at the models I've had in the past, review against om_nikc's one and then publish a draft strawman for critique... Downside is for a variety of reasons "i'm rather busy" so this will be a few weeks...

    However re TCO as a decision factor, I regard that as a yardstick for the real maturity, intelligence and metrics of the company's mngt - if ignored then short term, if included then mid/long term (good).

  5. I think two things are needed: one is a simple template for calculating internal TCO (for dunces like me who forget bits), the other is a mechanism for sharing depersonalised data between organisations which is not amenable to Evil Sales Weasels manipulating it. I'm up for the sharing part.