COTS: Is it Just a for Your Program? - commercial off-the-shelf

Program Manager, March, 2000 by Luke Campbell

Or Are You a Real Part of Acquisition Reform?

The subject of Commercial Off-the-Shelf (COTS) is complex because there is no single COTS issue -- there are many, depending on your perspective and position in the acquisition life cycle. In addition, the overall picture remains clouded by wild speculations about COTS savings and advantages, which are at least partially true. Any new concept requires some amount of hype to establish a critical mass to get it underway. We are beyond that stage with COTS, and the facts must now emerge. In this article, I examine COTS effects on three broad life cycle phases: development, support, and future growth or upgrades.

A Little Background

COTS is often touted as "we-do-it." However, if a program truly embraces COTS, it becomes apparent that while some acquisition changes are required during development -- substantial changes are required during support.

To many, COTS is synonymous with computers. Most "computer experts" have only minimal understanding of COTS and base their acquisition goals on a wholly insignificant view of the life cycle. To be blunt, just because you have a computer on your desk, does not make you an expert on the subject of COTS use. The primary differences between COTS in desktop systems and COTS in weapon systems are desktop integration vs. platform integration and life cycle times. Big differences. More will be discussed on these later.

You might say there are two COTS philosophies: Little COTS and Big COTS. Little COTS philosophy says, "We looked at commercial systems," or "We use an Intel processor." The information in this paper is based on Big COTS philosophy regarding the E-2C aircraft and its Mission Computer Upgrade (MCU). A sampling of Big COTS in the MCU is as follows:

* The operator-display workstations are developed from a performance-based specification, which is not under the control of the PMA.

* MCU runs a UNIX Operating System (OS).

* MCU uses operational software in C , which is developed by a University.

* MCU is connected by Ethernet to a mission computer repackaged to fit in the existing volume, but with no de sign changes from its commercial counterpart.

* MCU also runs a second commercial UNIX OS.

* COTS Cooperative Engagement Capability hardware and software are connected by a second Ethernet connection.

All these highly volatile systems must play in tune. This is more than just a considerable configuration management challenge: a methodology must also be in place for Technology Insertion (TI). This is Big COTS.

The concept of, "Just insert new technology during production," ultimately became one of the most questionable strategies used to initially support the COTS philosophy. It implied two major considerations that were, apparently given little thought at the time:

* COTS didn't need to be tested.

* Somehow, money would be appropriated for this condition.

Attempting to cross-dress a well-known concept in a simple-office PC environment to a complex weapon system with an even more complex acquisition cycle -- the support process -- can lead to disaster.

Disaster? What Disaster?

The E-2C operator workstations were developed by a sister Systems Command (SYSCOM) under a performance-based specification. Many units were not functional when installed into our system. Simple solution, fight? Just get the vendor to fix what's broke. The problem was that the units weren't broke. Since the delivered products all passed contractor-factory acceptance tests, there was nothing for the vendor to fix. Perplexed? So were we. One of our first lessons learned was that Class II changes to the vendor became Class I problems in our system. After considerable discussion about this situation, the vendor was very amenable. Establishing many Process Action Teams, over a period of one year the vendor made sweeping analysis of sub-vendors and developed very detailed processes -- but the results of the product did not change. Problems such as this occur several times each year, and program managers electing to use COTS must be prepared to solve them.

Our solution is a Program Support Activity (PSA). The PSA subsumes the classical Software Support Activity (SSA) functions, but adds the critical functions of Technology Insertion, a clearinghouse for Configuration Management, and what we call color-coding. More will be discussed on this later.

A Bumpy Start -- A COTS Failure

We tried to use as much COTS as possible. One of the first things we tried was to use the COTS databases. We found that they were big -- very big and S-L-O-W -- glacial, to be exact. The basic problem with commercial databases is that "realtime" to them is similar to a transaction at an Automated Teller Machine (ATM). During the same time it takes for that "fast cash" ATM transaction, several enemy fighters need to be shot down. "Tactical" to these commercial databases means to get the card out of the ATM because it's dark, and the person coming up behind you is unknown. For DoD, several missiles impacted a destroyer in this same period. "Oops."