BOX 2.2 Interoperable Systems Are Not the Same as Joint Systems
An airborne command and control system for air-to-air engagement could be designed as an Air Force system but its air picture would have to be displayable by Army air defense units and Navy ships. Likewise, the Navy might design a system for AEGIS air defense of the fleet, and the Army might design a surface air defense system. If an integrated air picture is to be shared by all three services, the data from each of the three service air defense command and control systems, which each provide an air picture based on data from the system's own sensors, must be exchangeable. Such service air defense command and control systems would be interoperable but not joint.
The Army might design a surface-to-surface artillery command and control system. The Navy might design a ship-to-shore naval gunfire system. Because targets might be able to be attacked by either the Army or Navy weapons, it would be useful to be able to pass attack orders between the two systems--setting a requirement for interoperability but not jointness. As the Navy develops its Cooperative Engagement System to integrate both naval surface-to-air and surface-to-surface firepower, it would be useful to be able to share its target information with Army air defense and field artillery systems, and likewise share the Army system capabilities with the Navy system. If, however, it were ever desired to receive requests, determine targets, and automatically to fire on air and surface targets using either Army or Navy air defense or surface-to-surface firepower, it would make sense to develop a joint fire control system. Such a system would be considered joint because it would be employed by both services and would control the use of resources from both services.
The U.S. Transportation Command could develop a command and control system to allocate air and sealift. The consumers of the command's transportation services may never need to use the system directly themselves, but would be interested in interoperability considerations such as the ease (form) of inputting lift requirements and of reading the output to determine what items need to be prepared for each lift asset. If this same system were to allow consumers to themselves conduct assessments of alternative deployments, it would then be considered a joint system because input form, run time, and output form might be of critical concern to consumers from all of the services. However, this does not mean that such a system would have to be developed and procured by a joint program office as opposed to that of a single service lead (with requirements input by the other services).
With the advent of the Joint Force Air Component Commander, who integrates and can employ all air assets, the next version of software to produce a joint air tasking order should probably be a joint development. This system should be used by both the Air Force and the Navy, should accommodate the uniqueness of each service, should decide or assist in the decision of the best assets to be employed (regardless of service), should integrate service assets (e.g., naval attack aircraft and Air Force tankers), and should provide a single, integrated order. This joint air tasking order development system could be used by both services to produce their air tasking orders when each is operating separately and could be used to produce a joint air tasking order when a Joint Force Air Component Commander has been established.