Using COTS Products

Initial Build

During the initial build of a system the use of COTS products can dramatically reduce
the time required to deliver the system. This is the case if the products are well
understood by the developers, or where the product provides functionality which
would be expensive to reproduce from scratch. Conversely, the gains can be quickly
lost if the products turn out to be poorly documented or of poor quality.

When there are several products involved it may be more expensive than initially
expected to get the products to correctly interact with each other. It will often be the
case that some bespoke code is required to smooth over the differences.

It is important during the initial build to document exactly what features of each
product are being used. It is also strongly advisable to create a set of tests that can
ensure that new versions of the COTS software still perform the required actions as
expected.

Licenses

COTS products are often sold with some form of license. Often the license will
include some form of lock that prevents the software from being used on alternate
hardware.

The cost of managing the licenses and the constraints placed on how the system can
be deployed must be taken into account.

Data Formats

One of the aims of commercial software vendors is to keep their customers for as long
as possible, and to have them buy new versions of the product as they are released. A
common tactic is to use a data format which is difficult for other products to use. (A
typical example is Microsoft Word which has been renowned for having an
indecipherable format that few other products could interpret.)

The problem with this approach is that it can be difficult to use the product as a
component in a larger system. And, of course, it also makes it difficult to swap the
product out and replace it with another one at a later date.

Upgrade Cycles

When a system consists of several COTS products the maintainers of the system will
eventually be faced with the decision to upgrade to new versions.

The products are unlikely to all require upgrade at the same time. An upgrade to one
product may necessitate the upgrade of other products if the suppliers have made
some attempt to have their products be compatible.

There is usually some point at which upgrades cannot be postponed, such as when the
operating system needs to be upgraded.

Our experience is that this point arrives about every four years for the UNIX
environment. It may be more often in the Windows and Linux environments.

Product Evolution

The suppliers of the COTS products will usually have their products evolve over time
as an incentive for customers to upgrade for the nice new features. When it comes
time to upgrade the system it is possible for the COTS products to no longer provide
the features or interfaces that they did during the initial system build.

COTS products have, almost by definition, a short lifespan. Any such product that is
at all useful is now faced with competition from other vendors, and also from the open
source community. Hence the product must evolve quickly to provide new
functionality or soon be rendered worthless.

It should also be noted that COTS products are actually a rather small (~10%) niche
in the software industry as a whole (most software is written to control some hardware
or business system). The idea of a software component as a commercial product is
quite strange from the economic point of view as it has a near zero cost of production
(but a high cost of development).

Product Obsolescence

COTS products can become obsolete. For example, a package that was used as part of
the system may be withdrawn from sale as a separate product because the vendor
wants to sell it as a part of a larger product.

The vendor may decide to no longer support the platform that the system is running
on. Building a system that runs across multiple platforms is a complication most
support teams could do without.

The vendor can also go out of business, making the acquisition of a new version
impossible.

The immediate impact of this obsolescence will depend on the license mechanism
being used. If the product must contact the vendor's server to operate then the impact
would be immediate. If the license involves a lock to the hardware or network
configuration then you may be able to operate for some time. If the license is time
limited then the crisis point will be predictable.

When to Use COTS

From our experience in maintaining a system for a very long period our advice would
be "as infrequently as possible".

If a system is expected to have a short life time before it is completely replaced then a
COTS solution may be viable, especially if it gets the system into production quickly.
If the entire system is one COTS product, such as an entire HR system, then it may
also be worth considering. The main issue with this approach is how far do you
modify the business to satisfy the product?

If the COTS product provides some function which would be very difficult to
implement, then it may be the only alternative.

COTS to Avoid

Our experience has demonstrated that building a system from a suite of small COTS
products is not a viable long term solution since they tend to evolve in different
directions, and some may cease to exist.

Products that have onerous licensing requirements might be more expensive to
manage than they are worth.

Products which do not provide well documented or open data formats may lead you to
a lock in situation and huge data conversion costs in the future.

Alternatives

The obvious alternative is to build it yourself. This may not be viable in the short
term, but if the system is expected to last for many years then a process of continuous
gradual redevelopment can result in a system which very closely matches the
requirements of the business.

The Open Source Software movement may be able to provide alternatives to the
commercial products. The advantages of OSS include the absence of license costs, the
use of open data formats and access to the source code. OSS can give the same
benefits as COTS during the initial development - perhaps even more since the source
code can be examined to get the fine details of interfaces and data formats.
Maintenance is simplified with OSS as the maintainers can, if they wish, avoid
upgrades and just recompile for the new environment. The emphasis on openness with
OSS avoids issues of later data conversion costs and problems interfacing the
software.


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.