Effective calculation of the total cost of ownership of software
In the previous article, 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 for good reason. Ate it is not fixed, here:
<sarcasm>
Vendors always fully 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 of the calculation of the TCO system before its launch. Open Source supporters often rush to point out the low initial cost of their systems. Critics point to potentially higher maintenance costs. OSS proponents 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. TCO of any IT system can be divided into four components:
')
* System acquisition cost
* The cost of switching to a new system
* Cost of system maintenance
* The cost of failure of the system
Each of these must be taken into account when evaluating an update.
In this section, free software has a distinct advantage. At zero cost, it is a clear winner ... At the present time, many commercial software development firms have learned this in practice, and provide free products in areas where there are competitors from open source software. Such companies are focused on paid support, as only they have access to the source code of the product, and they are the only ones who can actually provide support.
Of course, the cost of a standard delivery can only be part of the story. Often, software requires refinement for use in a particular business. If you use free software, then you can have more 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 the scripts.
If you decide to modify free software, then you must either support it in your organization or add your changes to the main version. The first option can be costly - you have to pay someone who will periodically merge changes from the main tree into your copy - but this option can be a competitive advantage in the short term. If you simply use 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 correct errors in them. Even better, if the changes you need are useful to others, then perhaps you can share the cost of development with them.
Awesome discovery is something that some people need to understand that some menu items are located in Microsoft Office and OpenOffice in different places. Even more striking is the fact that these same people have nothing to learn, where they moved the same menu items in different versions of MS Office.
Adaptation to any new system takes time. It may also have additional dependencies - for example, a new web application may require a new DBMS. Or, require staff training.
Be objective when evaluating your transition cost. If your staff needs significant retraining to transition between different word processors, then they are probably not using their current tools effectively. If this is the case, then you might consider switching to something completely different, like a web interface and a template system — something that would give a much more problem-oriented approach.
System administration skills are slightly different. The administrator must be familiar with all the capabilities and fads of the specific software. This may require some form of training, which can be partially compensated if there is a strong developer community.
Much 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, it is often cheaper. This applies to both open and closed source 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 a metaphorical or literal periodic oil change. In the case of programs, the main form is to install 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 site. Often this means that you need a spare system for testing, which has the same configuration as the working one.
Security updates are a sharper action. In many cases, the vulnerability can be published before the patch is released, making this system vulnerable. Even if not so, then for a cracker, the reverse engineering of the patch to identify vulnerabilities will be completely obvious.
The release schedule for fixes is also an important factor. If patches are issued on a regular basis, it is easier to plan their installation, which reduces the cost.
If a product has a bad security report, your administrators are likely to take interim measures between publishing a vulnerability and installing a proven patch.
The most important - and overlooked - final cost. At some point, your new great system will become obsolete. There are many possible reasons for this. A manufacturing company may stop supporting, or just 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?
Nowadays, open standards are becoming important. If your system adheres to standards, then it is relatively easy to replace it with something else - a fact that makes standards somewhat unpopular with vendors.
In the absence of chain standards, dependencies 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, then it will be relatively easy to transfer 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, then it is 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 programming interfaces to top-level data representations. If the software supports them (and is not unique at the same time), then it is relatively free from vendor lock-in .
Microsoft stubbornly emphasizes the low cost of switching from its products to its new products. Many UNIX vendors emphasize low maintenance costs and a lack of binding to the supplier.
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 fully 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 of the calculation of the TCO system before its launch. Open Source supporters often rush to point out the low initial cost of their systems. Critics point to potentially higher maintenance costs. OSS proponents 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. TCO of any IT system can be divided into four components:
')
* System acquisition cost
* The cost of switching to a new system
* Cost of system maintenance
* The cost of failure of the system
Each of these must be taken into account when evaluating an update.
Initial cost
In this section, free software has a distinct advantage. At zero cost, it is a clear winner ... At the present time, many commercial software development firms have learned this in practice, and provide free products in areas where there are competitors from open source software. Such companies are focused on paid support, as only they have access to the source code of the product, and they are the only ones who can actually provide support.
Of course, the cost of a standard delivery can only be part of the story. Often, software requires refinement for use in a particular business. If you use free software, then you can have more 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 the scripts.
If you decide to modify free software, then you must either support it in your organization or add your changes to the main version. The first option can be costly - you have to pay someone who will periodically merge changes from the main tree into your copy - but this option can be a competitive advantage in the short term. If you simply use 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 correct errors in them. Even better, if the changes you need are useful to others, then perhaps you can share the cost of development with them.
Transition cost
Awesome discovery is something that some people need to understand that some menu items are located in Microsoft Office and OpenOffice in different places. Even more striking is the fact that these same people have nothing to learn, where they moved the same menu items in different versions of MS Office.
Adaptation to any new system takes time. It may also have additional dependencies - for example, a new web application may require a new DBMS. Or, require staff training.
Be objective when evaluating your transition cost. If your staff needs significant retraining to transition between different word processors, then they are probably not using their current tools effectively. If this is the case, then you might consider switching to something completely different, like a web interface and a template system — something that would give a much more problem-oriented approach.
System administration skills are slightly different. The administrator must be familiar with all the capabilities and fads of the specific software. This may require some form of training, which can be partially compensated if there is a strong developer community.
Much 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, it is often cheaper. This applies to both open and closed source 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 a metaphorical or literal periodic oil change. In the case of programs, the main form is to install 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 site. Often this means that you need a spare system for testing, which has the same configuration as the working one.
Security updates are a sharper action. In many cases, the vulnerability can be published before the patch is released, making this system vulnerable. Even if not so, then for a cracker, the reverse engineering of the patch to identify vulnerabilities will be completely obvious.
The release schedule for fixes is also an important factor. If patches are issued on a regular basis, it is easier to plan their installation, which reduces the cost.
If a product has a bad security report, your administrators are likely to take interim measures between publishing a vulnerability and installing a proven patch.
The cost of failure of the system
The most important - and overlooked - final cost. At some point, your new great system will become obsolete. There are many possible reasons for this. A manufacturing company may stop supporting, or just 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?
Nowadays, open standards are becoming important. If your system adheres to standards, then it is relatively easy to replace it with something else - a fact that makes standards somewhat unpopular with vendors.
In the absence of chain standards, dependencies 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, then it will be relatively easy to transfer 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, then it is 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 programming interfaces to top-level data representations. If the software supports them (and is not unique at the same time), then it is relatively free from vendor lock-in .
Conclusion
Microsoft stubbornly emphasizes the low cost of switching from its products to its new products. Many UNIX vendors emphasize low maintenance costs and a lack of binding to the supplier.
It is important, before making a purchase, to carry out these calculations for yourself and see how much your decision will ultimately cost.
Source: https://habr.com/ru/post/62924/
All Articles