% fortune -ae paul murphy

Measuring TCO: Wintel vs Lintel

The most basic, and traditional, Wintel vs Lintel TCO comparison argued that since the hardware is the same, everything comes down to the cost of the OS and applications licenses -all of which are free for Lintel and expensive for Wintel.

This drew many different responses, but the two main trends I saw among independent experts working for Microsoft or IBM on this was to base headlined results either on assuming away the problem by comparing only non Lintel alternatives or on precise foreground calculations performed on numbers obtained by guessing high on one side and low on the other.

A favored tactic, for example, was to hide unreasonable assumptions in the fine print - or simply not to state them at all. It's common, for example, for these studies to assume that Lintel and Wintel investments have comparable lifetimes when, in reality, the squeaky wheel issue driven from Wintel insecurity and the upgrade cycle means that few Linux systems are replaced as often as Wintel ones. Similarly, you'll find otherwise obviously honest consultants blandly assuming that the human time required per Lintel "box" is the same as that for Wintel - but then quietly loading the cost comparison by citing minimal street rates for the MCSEs needed and roughly Sun Consulting's per diems for the Linux guys.

By mid 2004, however, enough people had bought into Red Hat's non license licensing to make Linux arguably more expensive to license than Windows, the Wintel community's continuing assertions about the long term cost of Linux use had moved the TCO debate into a kind of never never land where one set of assumptions is no more verifiable than another, and therefore the major players pretty much abandoned the field in favor of just assuming the issue away.

The junior players, of course, lacked the maturity to take that tack and as a result we saw quite a few web exposes (and even some nominally serious studies) that directly or indirectly started out with something like this: "We [asked around to find the most immature MCSE Linux phobes we could get, gave them all root access, and had them] set up our two test servers. Windows Data Center x64 Server 2003/XP Professional installed smoothly but we had some trouble hacking the network setup files on Linux. After two days of intensive configuration work on Linux, the Windows server was still running but our Red Hat support contact had become bizarrely unco-operative and, in the end, we did not get the application to load - advantage: Microsoft."

Somewhere in all this, of course, there's reality - and in my view that reality is pretty simple: the standard business school method for comparing two decisions, the NPV calculation, should apply to TCO comparisons.

Fair TCO comparisons, in other words, have to look at both cost and benefit streams.

To do what most analysts do: treat TCO as only the cost of ownership, is to argue that deceleration is different from acceleration: it isn't, and costs need to be assessed net of benefits. You don't, of course, often see Microsoft or IBM paying consultants to do this - but that's because things like desktop productivity comparisons between Vista and MacOS X, or performance comparisons between zOS and Unix, are serious losers for them.

In practice, however, the need to discount both cost and benefit streams to derive a real estimate for the cost of either the Wintel or Lintel decision means that people trying to form TCO estimates need to couch their work in terms of specific usage scenarios rather than generalities.

The reason for this is that the cost side, stuff like hardware, licensing, staffing, space, and power is easily generalized - meaning that they're comparable within major market categories like educational institutions, small businesses, or individuals - but the benefit side is not. People buy systems to do different things somewhat differently and so you can't really say what an application is worth to an organization or individual without specifying quite a lot of detail about where the application fits with whatever that organization or individual does.

I've tried to do a number of these - and the result, ultimately, is an argument by induction: do enough scenarios with enough internal variability and you'll discover that Lintel always beats Wintel if (and only if) the Lintel investment is properly managed.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.