Risks of Commercial Off-The-Shelf (COTS) Software


In many software projects, choosing the right architecture is very important factor to deliver reliable software. Having a large software system that required an appropriate architecture design that can fulfill the requirements of such software is hard enough to accomplish, and becomes problematic in many cases. With implementing the architecture that utilizes Commercial Off-The-Shelf (COTS) software based components to provide some functionality required for a system, will make such task even harder (SoftwareArchitectures.com, 2011).

COTS Possible Risks

The software architecture in any traditional software engineering would make the architectural decisions based on business objects, system requirements, and other constraints. Once the architecture plans are made for such software, some of the COTS components would be evaluated to provide some system functionalities (SoftwareArchitectures.com, 2011). By choosing such approach in the architectural design might add additional risks that can’t be controlled. Some of the unforeseen risks in such situation are: the COTS vendors may choose not to support the existing components in the future; or such vendors might be out of business.

Clapp (2001) explained that recognizing the risks involved in the integration of multiple products into a COTS-based system is an important task that required actions within any software project. There are three major sources of risks that need to be addressed when it comes to COTS-based systems:

  • Operational requirements – Using a COTS-based system might raise risks of not delivering the required performance and functionalities requirements of such system.
  • Technical approach – The technical characteristics of the COTS products might raise risks through the impact of such characteristics on the integration of such components with the system. 
  • Business strategy – Risk associated with the vendors of the COTS products where the vendor support of the products and the availability of such support might impact the business strategy over time.

Clapp (2001) also pointed out that to control COTS risks, the following are important techniques that should be considered:

  • Market research – The rapid turnover in the COTS products can be both a missed opportunity and risk that organization might not be aware of it, and as such; market research is required for any organization to anticipate, and recognize the market related risks.  
  • Early and frequently user involvement – It’s important for any organization to plan and address the systems users’ requirements, and involving users in such process in the early stage of the software project to determine the selection of  the COTS products. Involving the users in such early stage, can result in modifying some of the operational requirements to meet the capabilities provided by the COTS products.
  • Early and frequent integration – The early establishment of COTS product integrated laboratory, and operation can uncover a lot of risks involved in the COTS products such as reliability problem, response time problems, scaling up the system load problem or consuming too many resources problem.
  • Planned replacement and obsolescence – using COTS products can take from any organization the control over which features of the product can be modified or when the products are upgraded. Understanding such product’s restrictions will allow organizations to mitigate such risks by planning activities to refresh the software COTS products, and the hardware on a regular basis.

Steps to Reduce COTS Risks

It’s also important to point out that because of the nature of the COTS; the requirements-driven software development lifecycle is no longer suitable for the traditional software engineering used to meet the system requirements. Such problem forced the Software Engineering Institute’s (SEI) COTS group to try to address the deficiencies of the traditional software engineering approach, and to try to create an integration process that can align the COTS-based system, with the traditional software engineering approach.

The SEI process’s essence is based on simultaneous tradeoffs between the architecture considerations, the stakeholders’ needs, marketplace situation and risk within the software projects. With such approach, the potential COTS candidates must have the abilities to be in line with requirements of the system. The group created an Evolutionary Process for Integrating COTS-based systems (EPIC) that addresses the needs of COTS (SoftwareArchitectures.com, 2011).

The EPIC is a negotiation-driven process where it provides features by COTS that influenced the system expectations of the stakeholders, and the system requirements. With such process, the system knowledge grows incrementally, the system requirements are prioritized, the availability of the COTS components is continuously evaluated, and the risks are identified (SoftwareArchitectures.com, 2011).

Through each iteration, the risks evolve the COTS will narrow the selection the COTS alternatives, and the goal of the iterative process is to narrow down solution alternatives with time. The iterative process is based on the Rational Unified Process (RUP). The tradeoffs between having such components built in house, and COTS components are flexibility, development time, and control. Also, with the restrictions provided by the COTS components (treated as a black-box in that case), it is imperative that the appropriate stakeholders to be involved in the selection with the aspects of the system that are not controlled by the software architects (SoftwareArchitectures.com, 2011).


Carney (2011) explained that it’s clear that integrating COTS product in complex software poses many challenges to any organization, and as such; risk assessment for such products is required within any software projects to ensure that such product will meet the technical and the functional requirements of the system.

Finally, the right stakeholder’s involvement in the early stage of the product selection, and also the early investigation of the product characteristics can help uncover the risks involved in such product.


SoftwareArchitectures.com (2011) Software Architecture and COTS Software [Online]. Available from: http://www.softwarearchitectures.com/go/Discipline/DesigningArchitecture/COTSSoftware/tabid/65/Default.aspx (Accessed: 9 June 2011).

Clapp, J. (2001) Understanding Risks Alleviates COTS-based Systems Woes [Online]. Available from: http://www.mitre.org/news/edge_perspectives/march_01/ep_clapp1.html (Accessed: 9 June 2011).

Carney, D. (2011) COTS and Risk: some Thoughts on How They Connect [Online]. Available from: http://www.sei.cmu.edu/library/abstracts/news-at-sei/cotsmar00.cfm (Accessed: 9 June 2011).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: