Software Architecture and COTS Software

Choosing or designing an appropriate architecture to fulfill the requirements of a large software system is hard enough. The problem becomes acute when an architect is forced (or chooses) to utilize COTS-based components to provide some functionality of a system.

In a traditional engineering approach a software architect would make architectural decisions based on system requirements, constraints, and business objectives alone. After system architecture plans are stabilized a set of COTS components would be evaluated. According to Lisa Brownsword (SEI) this traditional engineering approach is not suitable for COTS based systems. There may be no suitable COTS components available to suit the specific needs of the envisioned system.

By choosing to use COTS an architect takes on additional risk that he or she cannot control. Vendors may go out of business, choose not to support the existing components, etc. In foreseeable future the time to market pressure will only rise, and customers will continue to expect software intensive systems to be delivered at a faster pace. Sooner or later architects will have to assemble some parts of a system from pre-built blocks, as building those elements from scratch will be cost prohibitive.

The playing field has changed. More and more projects will utilize COTS, and because of the nature of COTS the requirements-driven software development lifecycle (SDLC) is no longer suitable. The Software Engineering Institute’s (SEI) COTS group has been working to address the deficiencies of the traditional engineering approach. The group has developed an Evolutionary Process for Integrating COTS-based systems (EPIC) that addresses the unique needs of COTS. This iterative negotiation-driven process is based on the Rational Unified Process (RUP). The essence of the process lies in a “simultaneous definition and tradeoffs” between the stakeholder needs, architecture considerations, risks, and marketplace situation. The abilities of potential COTS candidates must be iteratively evaluated in line with requirements of the system.

EPIC is a negotiation-driven process where the features provided by COTS influence the requirements and expectations of system stakeholders. For example, if a user wants to retrieve some information in a certain format, but COTS components only provide the information in a different format, then it may make sense to convince a user to accept a different information standard. This approach is different from the legacy “do what customer says” approach. EPIC requires system engineers to have a good understanding of the marketplace.

EPIC is also an iterative process where the knowledge about the system to be built grows incrementally. The needs are prioritized, the risks are identified, and the availability of COTS components (the marketplace) is continuously evaluated. With each iteration the requirements and risks evolve inline with the narrowing selection of the COTS alternatives. The goal of the iterative process is to narrow down solution alternatives with time.

The bottom line is that EPIC is not different from an iterative engineering approach of system development. COTS components are just another factor that an architect must consider when choosing or designing architecture of a system. Use of COTS has its associated risks, as COTS components can be thought as black boxes that just work. The tradeoffs between COTS components and homegrown components are development time vs. flexibility and control. Because COTS components are restricting by its nature it is critical for appropriate stakeholders to be more involved in those aspects of the system that are not controlled by a software architect.