Concept: Process Drivers for COTS Package Delivery
Building solutions based on pre-existing COTS packages is different from typical custom development and thus requires dedicated guidance. This page covers this issue by presenting the specificity of COTS-based projects and its implication on system development processes.
Main Description

The Four Spheres of Influence

Building solutions based on pre-existing COTS packages is different from typical custom development in that the COTS packages are not designed to meet the project's specification. COTS packages are built to satisfy the needs of a market segment. Therefore, an understanding of the COTS package functionalities and how they are likely to change over time must be used to modify the requirements and user business processes as appropriate, and to drive the resulting architecture.

When building solutions based on COTS packages, it is important to simultaneously define and trade off among the four spheres of influence defined by EPIC [ALB0702,ALB1102]]. Tradeoffs in this case are driven by the desire to leverage COTS packages from the marketplace. This is a fundamental change from traditional process models. Numerous projects have unsuccessfully tried to integrate pre-existing COTS packages by defining the requirements, then formulating an architecture to meet those requirements, and then trying to fit COTS packages into that architecture. Instead, an emphasis on the balance between the four spheres of influence is critical throughout the life of a project. The four spheres represent competing interests that must be considered in forming a viable solution that effectively leverages pre-existing COTS packages.

The four spheres of influence are:

  • Sphere 1 - Stakeholder Needs and Business Processes: This sphere denotes requirements (including quality attributes such as performance, security and reliability), user business processes, business drivers and operational environment.

  • Sphere 2 - Architecture and Design: This sphere denotes the essential elements of the system, the relationships between them, and how they fit with the enterprise system. The elements include structure, behavior, usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs.

  • Sphere 3 - Marketplace: This sphere denotes available and emerging COTS technology and products, non-development items and relevant standards.

  • Sphere 4 - Programmatics and Risk: This sphere denotes the management aspects of the project. These aspects consider the cost, schedule and risk of building, fielding and supporting the solution. Key to these management aspects are the cost, schedule and risk of changing the necessary business processes.

These four spheres are simultaneously defined and traded through the life of the project because a decision in one sphere will inform and likely constrain the decisions that can be made in another sphere. For example, a stakeholder need may be stated in a way that it cannot be satisfied by any known pre-existing COTS package.

Commercial Marketplace-Imposed Constraints

The unique characteristics of COTS packages introduce dynamics and specific constraints that must be accommodated.

A COTS Package is a software product that:

  • is supplied by a vendor;
  • is sold, leased, or licensed to an acquirer;
  • is used without modification of its code;
  • may be tailored to be integrated into the acquirer environment;
  • is supported and evolved by the vendor, who retains the intellectual property rights.

Based on these characteristics, Oberndorf, Brownsword, and Sledge identified the following attributes of COTS packages in An Activity Framework for COTS-Based Systems:

  • The marketplace, not one system's needs, drives COTS package development and evolution.
  • COTS packages and the marketplace undergo frequent, almost continuous, change.
  • Frequency and context of COTS package releases are determined at the discretion of the vendor.
  • COTS packages are built based on unique architectural assumptions that may not be applicable to the target organization.
  • There is limited visibility into COTS package internals and behavior.
  • COTS package assumptions about user processes may not match those of a specific organization.
  • "Vendor" is not a new name for subcontractor. Different relationships are required to have insight and to influence package changes.
  • COTS package components often have unsuspected dependencies on other COTS package components.

Derived Process Requirements

Any process that builds, fields, and supports solutions based on COTS packages must do the following:

  • Create an environment where COTS packages (and therefore the marketplace) drive the evolving definition of the solution. The ultimate control of critical COTS packages has passed from the hands of the project to those of the COTS package vendors. It is important to reconcile the diverse expectations of stakeholders with an evolving understanding of the capabilities of available COTS packages. Therefore, an environment that facilitates hands-on analysis of the COTS packages and continuous negotiation with stakeholders will be required for the life of the project. This will allow the evaluation of new and changed COTS packages and their impacts on evolving solutions.

  • Compose solutions from a diverse range of components. Solutions are built from a combination of components (e.g. COTS package components)--both hardware and software--and many components are themselves built from components. Insight into the inner workings of these components will vary (e.g., black, white and gray box) depending on the source and the intended use of the component. Engineers must infer the behaviors of various component combinations as they integrate the components they buy or otherwise procure. Hands-on experience is essential with any component critical to the success of the solution. This experience should be in an environment that closely represents the operational use of the component.

  • Implement disciplined iterative systems engineering practices. Iterative development allows the discovery of the critical attributes of the solution through an evolutionary exploration of the highest risk elements of the system and the COTS packages available to address them. Iterative development also encourages frequent and direct feedback from all of the affected stakeholders through evolving prototypes that characterize and mature the architecture while reducing risk in the solution.

  • Support concurrent and integrated implementation of engineering, business and procurement tasks. The volatility of the COTS marketplace means that decisions about the COTS packages used; the structure that accommodates them; and the associated cost, schedule, and risk of the project are made continuously through the life of the solution. In addition, an engineering decision to include a new COTS package is also a decision to acquire the package from its vendor. The engineering processes, management processes, oversight processes and procurement processes of the project must be coordinated to support the flexibility and negotiation of requirements and iterative definition of the solution.

  • Balance component obsolescence and solution stability. Due to the volatility of the marketplace, a new COTS package or a new release of a COTS package being used can be introduced at any time during building, fielding, or support of the solution. Engineers must continuously monitor the marketplace through the life of the project to anticipate the changes being made. An environment is required where new COTS packages and releases can be evaluated and their potential impacts assessed.

  • Develop and maintain a flexible system architecture as a centrally managed asset. Since the COTS packages are "owned" by the vendors, the framework by which the components are linked to support the organization's needs--the architecture--becomes a key organization asset. With COTS-based systems, continuous, rapid changes driven by new mission needs, component upgrades and technology advances are facts of life. An architecture that can retain its structure and cohesiveness yet allow the system to respond easily to these changes--an evolvable architecture--becomes an important strategic asset to an organization.

  • Design with components versus design for reuse. Building a solution is an act of composition and reconciliation. Designers start with a general set of needs and explore the offerings of the marketplace to see how closely they match the needs. They then design an architecture around the pre-existing components. Building systems for reuse, on the other hand, has come to mean designing and building structures and components that can be used again in related systems. In this case, the designers have direct visibility and control of the components. The nature, timing and order of the tasks and the processes used differ accordingly.

  • Incorporate tasks for changing the user's business processes. Using COTS packages in solutions is not compatible with simply automating a predefined set of business processes. Since components embody the vendor view of user business processes, changes to the user's business processes must be negotiated based on those inherent in the COTS packages under consideration. Engineering tasks should be coordinated with tasks for changing the user's business process to ready the user community for fielding of the solution. The risks and implications of changes to the organizations where the solution is fielded may be significant drivers in the project. The definition and implementation of user business process and organizational changes must be coordinated through the life of the project.

  • Maintain and document how the COTS package supports the solution. Many COTS packages have diverse functionality, not all of which is required in a given solution. It is important to document the functionality applicable to the solution. It is just as important to capture how any excess functionality is handled within the solution-especially any functionality that is blocked or bypassed. Guidance and training on any solution-specific use of the application will have to be considered as part of the deployment artifacts. Furthermore, some of these "excess" capabilities will find their way into operational use after fielding. The ways in which the COTS packages are actually used within the organization must be tracked and captured. This information is important to the evaluation of new COTS package releases after solution fielding, as vendors may make changes in segments of the component that were not originally considered part of the solution.