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.
|