bilities that were not expected. Those unexpected resources invariably were not anticipated in the systems engineering process, from either a concept of operations viewpoint or a technical interface viewpoint. To the extent time and technical capabilities are available, the operator will find a way to accommodate these unplanned resources. This situation is even more amplified in joint operations. When the Joint CINC gathers his forces, he will attempt to piece together capabilities from the available resources. Often he will perceive an opportunity to connect complementary capabilities that were not products of common systems engineering.
Acquisition people live in the world where systems engineering is constrained to encompass only those capabilities that are based on validated requirements and priorities. These requirements are usually based on a concept of operation that makes assumptions about the resources and threats that might be justified 5 to 10 years in the future. These people are further constrained by the myriad of legacy systems with which they must interoperate. There is ample justification for such a process in a world of predictable threats, understood needs, and constrained resources. However, this traditional systems engineering approach will not yield a BMC3 system that meets the Navy's needs for future theater missile defense because of uncertainties in the projections of threats and of the capabilities and technologies needed for managing TMD. The time cycles for evolution of the technology and for evolution of the threats are both inside the systems engineering cycle. Furthermore, as was previously described, for the Navy to participate effectively in theatre missile defense, it must accommodate systems outside its control.
This leads to the conclusion that the Navy must plan for the system to be jury-rigged. More precisely, the Navy needs a BMC3 architecture that accommodates the introduction of unplanned resources and capabilities. This does not imply abandoning systems engineering or abandoning the requirements process. Rather it implies development of an open BMC3 systems architecture within which the systems engineering and priority setting must take place—an architecture that plans for unanticipated capabilities that will be introduced at a later time.
The difference between jury-rigging and having an architecture into which new capabilities may be introduced is profound. While both require creativity, the difference is how the creativity is used. In jury-rigging, creativity is wasted in figuring out how to pass information and in solving timing differences between two systems that were designed with different architectures. In the open systems approach, the creativity is used to choose the protocols, standards, and interface definitions applied to the process of building value-added capabilities that facilitate the identification, correlation, and other BMC3 functions.
Much has been said about system architecture in recent years. The Defense Science Board and the individual Service advisory boards have dealt with the