Efficient Software TCO Calculation
- Transfer
In a previous article in The Cost of Free Software, I pointed out Microsoft's complete objectivity in estimating the total cost of ownership ( TCO ) of Windows when comparing it with free software. Unfortunately, due to a bug in Firefox, when displaying the sarcasm tag, some readers took this statement at face value. If they haven’t fixed it yet, then:
<sarcasm>
Vendors always completely reliably and reliably calculate TCO, and would never distort the statistics or choose the most favorable configurations.
</sarcasm>
It is important that the organization can make its own definitions for calculating the TCO system before it is launched. Open Source advocates are often in a hurry to point out the low initial cost of their systems. Critics point to a potentially higher cost of maintenance. Supporters of STRs focus more on aspects of freedom and the corresponding low cost of migration. All these points are true, but none of them describes the situation as a whole. The TCO of any IT system can be divided into four components:
* The cost of acquiring a system
* The cost of upgrading to a new system
* The cost of servicing a system
* The cost of abandoning a system
Each of these must be taken into account when evaluating an update.
Free software has a clear advantage in this section. At zero cost, it is a clear winner ... At the present time, many commercial software companies have learned this, and provide free products in areas where there are competitors from open source software. Such companies focus on paid support, since only they have access to the source code of the product, and they are the only ones who can really provide support.
Of course, the cost of standard delivery can only be part of the story. Often, the software requires refinement for use in a particular business. If you use free software, then you can have a lot of flexibility in this matter, because you (or the contractor hired by your company) can directly modify the code, instead of working through a set of provided interfaces and screwing up scripts.
If you decide to modify the free software, then you must either keep it fork in your organization or make your changes to the main version. The first option can be expensive - you have to pay someone who will periodically merge the changes from the main tree into your copy - but this option can be a competitive advantage in the short term. If you just use the software, and do not build your business around it, then you don’t lose anything by releasing your changes, and you benefit from the fact that other people will help to correct errors in them. Even better, if the changes you need are useful for others, then maybe you can share the development cost with them.
A terrific discovery is that it is worth some to understand that some menu items are located in different places in Microsoft Office and OpenOffice. Even more striking is the fact that the same people do not need to learn anything where they moved the same menu items in different versions of MS Office.
Adapting to any new system takes time. It may have additional dependencies - for example, a new web application may require a new DBMS. Or, require staff training.
Be objective when evaluating your conversion cost. If your staff needs significant retraining to switch between different word processors, then they probably do not use their current tools effectively. If this is the case, then you could consider switching to something that is completely different, like a web interface and a templated system - something that will give a much more problem-oriented approach.
The skills of system administration are somewhat different. The administrator must be familiar with all the features and quirks of a particular software. This may require some form of training, which can be partially offset if there is a strong community of developers.
Most commercial software requires some degree of customization and is often supported by a third-party organization. If there is an opportunity for third-party support, then often it is cheaper. This also applies to open and closed software; however, this is more typical of Free Software.
A very small number of systems, hardware or software, can be installed and forgotten. Most require metaphorical or literal periodic oil changes. In the case of programs, the main form is the installation of updates from the supplier.
Most updates are thoroughly tested before release. Unfortunately, it is impossible to test all possible combinations of hardware and software that can cause problems, and often some additional testing is required on the spot. Often this means that you need a spare system for testing, which has the same configuration as the working one.
Security updates are more shaky. In many cases, a vulnerability can be published before a patch is released, making the system vulnerable. Even if not, then for the cracker, reverse engineering of the patch to identify vulnerabilities will be completely obvious.
The release schedule is also an important consideration. If patches are released on a regular basis, it’s easier to plan for their installation, which reduces the cost.
If the product has a poor security report, then your administrators are likely to take temporary measures between posting the vulnerability and installing the verified fix.
The most important - and overlooked - final cost. At some point, your great new system will become obsolete. There are many possible reasons for this. A manufacturing company may end support, or simply go bankrupt. Developers can decide to stop working on the system. This may be the lack of the functionality you need at the moment.
When you reach this turning point, you need to look for an alternative. How do you depend on the system? Did you use it to build critical infrastructure?
Open standards are now becoming important. If your system adheres to standards, then it is relatively easy to replace it with some other - a fact that makes standards somewhat unpopular with vendors.
In the absence of standards, dependency chains can be quite long. If you use software that is written using non-standard APIs, then you cannot easily replace your operating system. If this software stores its data in non-standard formats, then you cannot easily replace it.
If you choose an operating system that supports standards such as POSIX and X11, it will be relatively easy to port your existing source code to a new platform that supports these standards. If you do not have source codes, then there are binary translation levels that work well on isomorphic systems.
Similarly, if your data is stored in open formats, it’s easy to migrate between applications. If you use OpenOffice to create OpenDocument files, then you can switch to AbiWord (for example) without having to convert all your documents to the new format.
Standards exist in most areas of software development, from the lowest-level software interfaces to high-level data representations. If the software supports them (and not unique at the same time), then it is relatively free of vendor lock-in .
Microsoft is stubbornly emphasizing the low cost of migrating from its products to its new products. Many UNIX vendors emphasize low maintenance costs and a lack of vendor binding.
It is important, before making a purchase, to carry out these calculations for yourself and see how much your decision will ultimately cost.
<sarcasm>
Vendors always completely reliably and reliably calculate TCO, and would never distort the statistics or choose the most favorable configurations.
</sarcasm>
It is important that the organization can make its own definitions for calculating the TCO system before it is launched. Open Source advocates are often in a hurry to point out the low initial cost of their systems. Critics point to a potentially higher cost of maintenance. Supporters of STRs focus more on aspects of freedom and the corresponding low cost of migration. All these points are true, but none of them describes the situation as a whole. The TCO of any IT system can be divided into four components:
* The cost of acquiring a system
* The cost of upgrading to a new system
* The cost of servicing a system
* The cost of abandoning a system
Each of these must be taken into account when evaluating an update.
Initial cost
Free software has a clear advantage in this section. At zero cost, it is a clear winner ... At the present time, many commercial software companies have learned this, and provide free products in areas where there are competitors from open source software. Such companies focus on paid support, since only they have access to the source code of the product, and they are the only ones who can really provide support.
Of course, the cost of standard delivery can only be part of the story. Often, the software requires refinement for use in a particular business. If you use free software, then you can have a lot of flexibility in this matter, because you (or the contractor hired by your company) can directly modify the code, instead of working through a set of provided interfaces and screwing up scripts.
If you decide to modify the free software, then you must either keep it fork in your organization or make your changes to the main version. The first option can be expensive - you have to pay someone who will periodically merge the changes from the main tree into your copy - but this option can be a competitive advantage in the short term. If you just use the software, and do not build your business around it, then you don’t lose anything by releasing your changes, and you benefit from the fact that other people will help to correct errors in them. Even better, if the changes you need are useful for others, then maybe you can share the development cost with them.
Transition Cost
A terrific discovery is that it is worth some to understand that some menu items are located in different places in Microsoft Office and OpenOffice. Even more striking is the fact that the same people do not need to learn anything where they moved the same menu items in different versions of MS Office.
Adapting to any new system takes time. It may have additional dependencies - for example, a new web application may require a new DBMS. Or, require staff training.
Be objective when evaluating your conversion cost. If your staff needs significant retraining to switch between different word processors, then they probably do not use their current tools effectively. If this is the case, then you could consider switching to something that is completely different, like a web interface and a templated system - something that will give a much more problem-oriented approach.
The skills of system administration are somewhat different. The administrator must be familiar with all the features and quirks of a particular software. This may require some form of training, which can be partially offset if there is a strong community of developers.
Most commercial software requires some degree of customization and is often supported by a third-party organization. If there is an opportunity for third-party support, then often it is cheaper. This also applies to open and closed software; however, this is more typical of Free Software.
System Maintenance Cost
A very small number of systems, hardware or software, can be installed and forgotten. Most require metaphorical or literal periodic oil changes. In the case of programs, the main form is the installation of updates from the supplier.
Most updates are thoroughly tested before release. Unfortunately, it is impossible to test all possible combinations of hardware and software that can cause problems, and often some additional testing is required on the spot. Often this means that you need a spare system for testing, which has the same configuration as the working one.
Security updates are more shaky. In many cases, a vulnerability can be published before a patch is released, making the system vulnerable. Even if not, then for the cracker, reverse engineering of the patch to identify vulnerabilities will be completely obvious.
The release schedule is also an important consideration. If patches are released on a regular basis, it’s easier to plan for their installation, which reduces the cost.
If the product has a poor security report, then your administrators are likely to take temporary measures between posting the vulnerability and installing the verified fix.
System Failure Cost
The most important - and overlooked - final cost. At some point, your great new system will become obsolete. There are many possible reasons for this. A manufacturing company may end support, or simply go bankrupt. Developers can decide to stop working on the system. This may be the lack of the functionality you need at the moment.
When you reach this turning point, you need to look for an alternative. How do you depend on the system? Did you use it to build critical infrastructure?
Open standards are now becoming important. If your system adheres to standards, then it is relatively easy to replace it with some other - a fact that makes standards somewhat unpopular with vendors.
In the absence of standards, dependency chains can be quite long. If you use software that is written using non-standard APIs, then you cannot easily replace your operating system. If this software stores its data in non-standard formats, then you cannot easily replace it.
If you choose an operating system that supports standards such as POSIX and X11, it will be relatively easy to port your existing source code to a new platform that supports these standards. If you do not have source codes, then there are binary translation levels that work well on isomorphic systems.
Similarly, if your data is stored in open formats, it’s easy to migrate between applications. If you use OpenOffice to create OpenDocument files, then you can switch to AbiWord (for example) without having to convert all your documents to the new format.
Standards exist in most areas of software development, from the lowest-level software interfaces to high-level data representations. If the software supports them (and not unique at the same time), then it is relatively free of vendor lock-in .
Conclusion
Microsoft is stubbornly emphasizing the low cost of migrating from its products to its new products. Many UNIX vendors emphasize low maintenance costs and a lack of vendor binding.
It is important, before making a purchase, to carry out these calculations for yourself and see how much your decision will ultimately cost.