TCO and OSS: Where does the buck stop?
TCO
In any kind of software deployment, the issue of total cost of ownership is an important one. The concept of TCO was first introduced by Gartner approximately 10 years ago and is used to describe how the cost of software functions over the lifecycle of its implementation. Software tends to continually evolve, and this means that the cost of software is not one fixed figure, but is incurred over time, by a range of actions, for example, customization or upgrade. Depending on how tightly TCO is defined, the cost of ownership sometimes also includes the cost of hardware and other equipment in an installation.
The TCO of software therefore will vary according to the way it is implemented and the ease with which it can be maintained over time. Maintenance will almost certainly include some kind of customization and upgrade activity – and these will be performed to add new features or functions, for example, to add planning capability, as well as to extend the domain of the software – for example, in OSS to include a new service or technology.
In operations, traditionally software has been custom-developed as the capabilities required were not available through COTS (commercial off the shelf) software. The balance between inhouse and COTS software is changing however, as increasingly service providers find that they can source required functionality from a COTS software package. For service providers therefore, the issue of TCO needs new consideration, as TCO of COTS software has different parameters to TCO of inhouse developed software.
For example, when we talk about ‘upgrade’ of inhouse developed software, this is usually referring to a customization project – and this can be time-consuming and expensive, depending on how old the existing system is, and how much change is required. But for COTS software, upgrade refers to the installation of the latest version of the existing software package. While upgrade is sometimes coupled with other customization projects, assuming the package has been implemented in a standard way, upgrade itself should be relatively straightforward.