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

Meanwhile, however, System XYZ was fielded with a preplanned product improvement strategy, because the operational requirements were expected to increase dramatically over the course of the next few years. The upgraded system is due in two years, but because the current system implemented a few features early, it will actually continue to function effectively for the next 30 months. As a result of a funding cut, the PM is already warning that the upgrade will be three months late. Therefore, in 24 months we expect the system to enter the yellow state, where it is behind the acquisition cycle but still meets operational requirements. In 27 months when the next version is released, it will become green, and will stay green at 30 months because the system will still meet requirements.

APPLYING THE BASIS

The section above describes how each system can be graded using a modified stoplight-style scheme. Systems graded green and yellow meet their operational requirements, although yellow systems warn of possibly overspecified requirements or potential future problems. Systems graded orange and red limit operations. Red systems indicate problems in requirements implementation, whereas orange systems indicate a (potentially harder to solve) problem in requirements definition.

The problem with this scheme is that it may not provide adequate insight into the etiology (root cause) of the problem. Systems with multiple interfaces may be coded red because of problems with only one interface. Instead of grading systems, it may be necessary to unroll this rating and grade the interfaces between systems. Each pair of interacting systems could be given a color code based on the scheme described above.

The advantage to grading interfaces is a more fine-grained understanding of not only the systemic cause of the problem, but also of its operational impact. A red system may perform perfectly well in a large number of operational scenarios, if the most commonly required interfaces are not the causes of the problem. Conversely, it may have little operational value, if the most useful interfaces are the ones with the problem.

The disadvantage to grading interfaces is the dramatic increase in the magnitude of the problem space. With the increased interconnections between systems in the network-centric environment predicted by JV2010, we can expect increasing numbers of interactions between system pairs. Whereas the difficulty of measuring readiness for systems increases with the number of systems, the difficulty of measuring readiness for interfaces increases with the square of the number of systems.

One way to mitigate this problem would be to narrow the number of interfaces considered. Instead of grading all interacting system pairs, it may be useful to begin by evaluating the readiness of each system in the problem space. For red and orange systems, one might next evaluate each interaction with another system using the readiness reporting model, and then develop remediation plans on a per-interface basis. Once this process was established, yellow systems could be similarly analyzed to determine whether the requirements were overspecified or the systems underutilized, or whether (as in our earlier example) the yellow status was a transient situation that was not cause for great alarm.