Using COTS solutions
When to Choose COTS
In some cases, if there is a COTS system that will fit your end-user needs, then there may be an opportunity for cost savings.
Fully assess whether commercial off-the-shelf (COTS) solutions fit your project’s needs.
First determine, whether the COTS product will be to deliver a unique government service with public users, or is an intermediate tool for developers.
For products to be used by developers
A COTS product may make a lot of sense for developer tools. Before procuring a COTS developer tool, ensure that it is compatible with the development approach you are proceeding with. Is the developer tool commonly used by developers outside of government? If not, consider an alternative product. Allow your developers to test drive the product and gather their feedback as part of market research on the available products.
For products that the public will use to access government services
Be upfront about asking a COTS vendor allowing your users to test out the product. In the demo are they able to accomplish their needs? If not, how feasible are the changes to the system to meet your end user needs? Can you honestly assess whether those changes will be less costly than an open-source solution? Have other government entities successfully implemented the COTS product. If you can achieve clear answers on these topic from prospective vendors then you may want to consider COTS.
For products to be used by internal department staff
Administrative tools are often mostly likely to leverage COTS and the least likely to conform to the unique workflows and regulatory constraints of government. Rather than identify these requirements upfront conduct design research about what the workflows your staff conduct using existing tools and highlight what would be the most streamlined process possible. Then conduct an assessment of how closely the products that appear in your market research match the observed ideal workflows.
Acquisitions and technical factors to consider
In addition to the end-user considerations, in choosing whether the COTS system is right for your project, make sure to include following technical and acquisitions factors in your analysis:
- The transition from legacy systems
- Ongoing operations and maintenance costs
- Costs related to being locked-in to a single vendor
- Costs associated with maintaining custom features
Modifying COTS solutions can have unexpected costs.
Almost inevitably, COTS solutions require modifications in order to meet your needs. Configuring a COTS product to meet your needs is not inherently a problem, but we often see modifications to the underlying code base grow to the point where the system cannot handle any updates from the COTS provider. This poses security risks and can be a risk to the long-term viability of the tool.
If you can already see the ways that the COTS tool does not meet your needs, it’s worth asking if your process could be adapted to meet the way the software already manages it.
Alternatively, if process changes aren’t feasible, states can explore requiring the COTS provider to offer a plug-in or bridge API that would allow independently-developed custom code to meet the state’s unique business need without creating unique interdependencies that will compromise the maintainability of the COTS solution.
If the problem domain is core to your work and is where you would like to innovate rapidly, it will not make sense to choose COTS. On the other hand, if it is auxiliary to your work and you can adopt the process implemented by the COTS product, COTS would make sense.