[KLUG Advocacy] TCO Windoze vs Linux

[Robert G. Brown]

Folks:
   TCO is a much-abused term that has been used to justify (or denigrate)
a whole bunch of different things. I do not think people really understand 
what "Total Cost of Ownership" really means, even though the term sounds
simple. We often forget what it means. This thread shows evidence of both.

   TCO means just what it says, the total cost of the life cycle of a
product, from the moment it is first conceived until the moment that the 
last bit of equipment has been disposed of and falls off the depreciation
scheduled and out of the cost structures of the organization, and no long-
er has any energy or effort put into anything.

   In the real world, the only way you're going to perform good TCO 
analysis is when there's nothing there yet... that is, we're looking at
a blank field, or an organization that has no computing yet. I've been
lucky enough to participate in several of these studies; the freedom to
make choices and an atmosphere in which alternatives can be explored is
very instructive; it shows how little latitude we have much of the time.

   In organizations that already have a computing facility, TCO per se
may not apply; I feel it's a useful exercise in any case, but it simply
may no longer be applicable. "Partial TCO" or "TCO with a conversion" is
not TCO at all. This doesn't mean we can't be disciplined about assessing
costs, it is simply that the term "TCO" doesn't apply; we need another
term, and perhaps a different way to segment the costs.

   Now, if you really do TCO, Linux wins over anything from Redmond,
hands-down and moving away.  Let's take a look at how costs are struct-
urally different between these systems:

  1. The software itself is available for minuscule cost, vs. an ongoing
     stream of licensing and upgrade fees.

     Conclusion: Software Acquisition costs are far lower

  2. The spread between the compensation packages for Linux-oriented vs.
     MS-branded administrators and specialist is small, with margins on
     both sides. Variations between these groups are smaller than the 
     range introduced by seniority within groups.

     Conclusion: Personnel costs are in essence equal. Linux will provide
                 some economy of scale as networks get larger (more about
                 this later).

  3. Hardware costs are somewhat more modest for Linux than for MS-brand.
     This is a big topic; there are lots of reasons for this. We all know
     them, perhaps viscerally, I'll cite three:
     a. For many operations, Linux is simply more efficient. This is a 
        by-product of the Open Source Process. With more efficiency, we
        can use more modest (AKA "cheaper") hardware to accomplish the
        same goals.
     b. Linux can be tailored (maybe even "butchered") to provide dedi-
        cated functionality on commodity hardware..
     c. Radically lower cost of software acquisition translates into an
        ability to bettter tune hardware to the need at hand. If we don't
        have to pay premium costs per platform for software, we're more
        inclined to size everything to match the problem a lot better.

  4. Operating costs are lower. Since Linux has better MBTF than MS-branded
     software, it has a smaller footprint in the organization:
     a. Less support and help desk manpower.
     b. Less lost work and time due to workstation and server failures.
     c. Lower overall support work per host.

To sum up, Linux start out cheaper, is cost-competitive on the person-
nel side, lowers and stretches out hardware costs, and saves the organiz-
ation disruption-related costs. What we must understand is that we're not 
dealing with a temporary factor or margin that separates the two cost
structures, but reflects the rather deep differences in the underlying
business model.

Conversion Costs
================

Conversion costs are indeed part of TCO, but it can be accrued to either
technology, that is, the technology that is being exited, the new technology,
or allocated between the two in some way. This is in essence not a technical
issue, no technological assessment can fairly include this. In practice, the 
conversion is handled as a separate project; some components of such a pro-
ject are accrued to the new technology (like training), and some are credited
to the old technology (assessments of existing facilities). Alternatively,
some kind of allocation is made. The question "what will it cost to move
from technology X to technology Y?" is rather simplistic; anyone who looks 
at this effort seriously rapidly comes to understand this.

The real question that gets asked is "What's the pay-back time?" That is, 
how long will it take to amortize the conversion costs? If TCO is calculated
well, it can be used to make a convincing case for shorter pay-back times. If
pay-back time is short (3 years or less for medium to large organizations, 1 
year or less for small organizations), acceptance is going to be much more
forthcoming, especially if lengthening the life of depreciated assets (like 
old computers), and even more so if disruption-related costs are lowered.


Summary
========
There is a TCO study on the KLUG ftp site:

    ftp://ftp.kalamazoolinux.org/pub/kulg/tcocalc.ps

It is the result of a TCO study I was involved in, for a dental clinic 
that was started in central NJ, in 1998. It compares Linux and Win NT 
4.0, the prevailing top-end MS-branded product family at the time. I
have participated in other TCO and migration studies for other organiz-
ations, from the rather small size shown in the above study, up to large
multinational financial services firms. One surprising factor that is
shown by the study (and my experience on other studies of this type) is
the rapidity with which the costs of disruption add up (factor 4b in the
above outline).

A lot of FUD has been generated on this topic, particularly as vendors 
tend to pander to managements desire to cost-justify everything. While
it is true that no one has been fired for desiring lowered operating
costs, many do not quite know how to get there, and there is little
objective assesment of the components of TCO (or even knowledge of what 
TCO really is), and vendors take advantage of this.

                                                       Regards,
                                                        ---> RGB <---