An interoperability road map for C4ISR legacy systems - Opinion

Acquisition Review Quarterly, Wntr, 2002 by John A. Hamilton, Jr., Jerome D. Rosen, Paul A. Summers

Using these two methods, we arrive at a four-colored system, as described in Tables 1 and 2.

Note that use of the stoplight model involves drawing hard lines between meeting and not meeting requirements. This may not be an entirely straightforward proposition. Nevertheless, the value of drawing a line in the sand between "acceptable" and "unacceptable" cannot be overstated. Only by providing unambiguous judgments on the status of our systems can we move the debate from one of educated guessing (i.e., rumor and innuendo) to one with a degree of rigor and reproducibility.

There is one important point that needs to be made about this grading system. The operational requirements considered should be those that are in force at a particular time. If we are grading a system today, it should be graded with respect to today's operational requirements -- if we are projecting a grade for one year from now, it should be based on our best information about next year's operational requirements.

However, the acquisition requirements used should be those that were to have been implemented by a particular point in time. For example, if we have a radio system with a scheduled upgrade, and the requirements process was geared for release of the upgrade in one year, we should not include the upgraded requirements in an evaluation of the system's readiness today. We should, however, include the upgraded requirements in an evaluation of the system's readiness next year -- and we should do so using our best information about whether/when the system will meet these requirements. This is important (and fair) because we must recognize that the acquisition community is constrained by technical and fiscal realities, and does not always have the ability to deliver improvements in time. Its schedule is dictated by the ever-present trades with cost and performance, and may even be influenced by the timeliness of the identification of the requirement. This part of the measurement is designed to measure the acquisition community's ability to respond to the requirements process -- and schedule is a key part of that process.

Of course, in both cases, the farther in the future we project these requirements, the more cautiously we must consider their results. Nevertheless, short-and medium-term forecasts are likely to have tremendous planning value. Consider the following notional example illustrated in Figure 2.

System XYZ was fielded one year ago. The original release had some problems with one of its interfaces, and as a result was unable to pass JITC testing. Nevertheless, System XYZ was fielded because it provided significant capability to the Unified Commands. Unfortunately, its failures have limited its operational employment. Therefore, its current interoperability readiness status is red -- it has both operational and acquisition problems.

A software fix, just submitted for JITC testing, has undergone favorable initial review and is expected to resolve both the operational and acquisition problems. JITC testing will be completed in three months, so at that time we project that its interoperability readiness status will be orange. Three months later the software fix will be incorporated in all fielded units; so in six months, we project the interoperability readiness status will be green.