2.1 What is Interoperability And Why is it Important?
The full realization of Joint Vision 20101 and the revolution in military affairs, discussed in Chapter 1, is predicated on a concept of information superiority enabled and supported by a network of C4I systems—one whose constituent elements interoperate and cooperate to support the entire warfighting hierarchy, in the context of joint and coalition operations. Interoperability of C4I systems is a key enabler of the overarching operational goal of force integration—the fusing of the services and coalition partners into a unified military force that achieves high military effectiveness, exploiting and coordinating the individual force capabilities. Achievement of a high level of interoperability requires a commensurate level of effort and resource prioritization throughout DOD. Today, DOD is just at the beginning of refining and even establishing the processes and organizations to respond to future needs for C4I interoperability.
2.1.1 What is Interoperability?
Interoperability is a broad and complex subject rather than a binary attribute of systems. C4I interoperability is a key enabler for the conduct
of effective, collaborative, multi-service military operations across a wide spectrum of scenarios, and successful conduct of operations is the ultimate test of whether an adequate degree of interoperability is being achieved. Joint Chiefs of Staff Publication 1-02 defines interoperability at both the technical and operational level (Box 2.1).2 Operational interoperability addresses support to military operations and, as such, goes beyond systems to include people and procedures, interacting on an end-to-end basis. Implementation of operational interoperability implies not only the traditional approach of using standards but also enabling and assuring activities such as testing and certification, configuration and version management, and training. These definitions of operational interoperability encompass the full spectrum of military operations, including intra-service/agency, joint (inter-service/agency), and ad hoc and formal multinational alliances.
Interoperability at the technical level (see Box 2.1) is essential to achieving operational interoperability. An issue that arises between systems rather than between organizations, technical interoperability must be considered in a variety of contexts and scopes, even for a single mission. Consider the theater missile defense mission, which is likely to require that data be:
- Exchanged among elements of a weapon system. For example, the Patriot air defense system uses a defined message format and data link to exchange information within batteries and between batteries to share target information and coordinate defensive actions.
- Exchanged between weapons systems of a single organization or service . For example, the Theater High Altitude Area Defense system (under development) will provide theater ballistic missile tracks to Patriot systems.
- Exchanged between weapons systems of different services. For example, a Navy AEGIS radar may report tracks to an Army Patriot radar.
- Shared and "pooled" at the joint task force command and control systems level (or higher) in order to achieve synergy and added value . For example, Patriot, AEGIS, and Airborne Warning and Control System data may be combined to develop a common operating picture and to control and coordinate all the systems sharing data.
The range of complexity of requirements for data flow in such a mission underscores the significance of interoperability at every level.
Box 2.1 Interoperability Defined
The ability of systems, units, or forces to provide services to and. accept services from other systems, units, or forces and to use the services so exchanged to enable them to operate effectively together.
—Definition (1) in Joint Chiefs of Staff, Department of Defense Dictionary of Military and Associated Terms, as amended through December 7, 1998 (Joint Publication 1-02) and Chairman of the Joint Chiefs of Staff, Instruction 6212.01A: Compatibility, Interoperability, and Integration of Command, Control, Communications, Computers, and Intelligence Systems, June 1995.
The ability of systems, units, or forces to provide services to or access services from other systems, units, or forces, and use the services to operate effectively together.
—DOD Directive 5000.1, "Defense Acquisition," March 15, 1996.
The condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users The degree of interoperability should be defined when referring to specific cases.
—Definition (2) in joint Chiefs of Staff, Department of Defense Dictionary of Military and Associated Terms, as amended through December 7, 1998 (Joint Publication 1-02).
Interoperability is the ability of systems to provide dynamic interactive information and data exchange among C41 nodes for planning, coordination, integration, and execution of Theater Air Missile Defense operations.
—Joint Theater Air Missile Defense Organization (JTAMDO). 1997. JTAMDO Master Plan. JTAMDO, joint Staff, Department of Defense, Washington, D.C., Chapter 7.
One source of interoperability problems is incompatibilities in independently selected versions (e.g. software releases) of the same system. Thus, if one unit has standardized on version A of a given system and another on version B, capabilities supported by one system and not the other may well interfere with seamless interoperation between the two units. The committee observed several such situations in its visits to exer-
cises. Also, just as differences in modes of operation across the services can lead to non-interoperability, so can organizational differences within a service also lead to intra-service incompatibilities. One example that the committee heard about involved information security procedures and practices that were different in the U.S. Atlantic and U.S. Pacific commands, presenting difficulties for units that are reassigned from one theater to another.
When thinking about C4I it is important to understand the distinction between joint systems and systems that are interoperable (Box 2.2). A system is designated as joint either to support an efficient buying decision for two or more services that will use it, or because the system will be subject to joint command. By contrast, to meet requirements for interoperability, services' systems must be able to share data in a timely, reliable manner that is operationally useful, and must operate across service or agency boundaries to support joint missions. Interoperability does not necessarily imply joint (multiple service) programs; interoperability can and must be achieved without jointness. Joint programs are but one of a number of management approaches for achieving interoperability of systems among the military services.
Although many view interoperability as an issue arising in the context of two or more services (or nations), fielding a wide variety of mature systems built with little attention to supporting joint or coalition operations,3 in fact its sphere is broader. Indeed, during its site visits the committee heard several examples of C4I systems owned and operated by the same service that have difficulties in interoperating. For example, in one visit, the committee observed that with the Army Forward Area Air Defense Command, Control and Intelligence System and the Maneuver Control System there were difficulties in overlaying data from one system with data from the other.
Finally, although it is a critical enabler for military operations, interoperability must be recognized as just one of several technical attributes of any system of systems. Indeed, other attributes will sometimes be in competition with interoperability and with each other; an appropriate balance must be sought. For example, there are trade-offs between security and interoperability. Interoperability can promote an attacker's access to diverse systems, thus facilitating the rapid spread of attacks. Also, ad hoc work-arounds to overcome a lack of inherent interoperability can
BOX 2.2 Interoperable Systems Are Not the Same as Joint Systems
introduce many hard-to-manage security problems. Another trade-off is the potential for interoperability problems posed by the introduction of new security features into part of a larger system of systems. Thus, in thinking about overall system functionality or performance, security requirements such as confidentiality, authentication, non-repudiation, integrity, and system availability must be considered together with interoperability.
2.1.2 Why Interoperability Is Important
Why is interoperability, which is so difficult to achieve, so essential to implementing current doctrine as well as emerging concepts of operation?
Experience in operations such as Desert Storm and Bosnia, as well as evidence from recent experiments and exercises, points to the dramatic improvements in operational effectiveness that are achievable using highly capable C4I systems. The leverage provided by a common operating picture and the rapid decision-making ability associated with it can dramatically change the pace, nature, and geographic range of engagement, providing major advantage to forces so enabled. Interoperability is a key to realizing these advantages.
Interoperability is also an important factor in operational efficiency. Where interoperability is lacking, there is the likelihood that multiple systems are performing the same functions, or that information is being manually entered or processed multiple times. And lack of interoperability also means that personnel have to resort to work-arounds. Where interoperability is not in place, necessary transfer of information between systems may require speaking over a voice link or rekeying data from
printouts or handwritten notes, processes that are not only inefficient but error-prone as well.
Military operations are typically joint, requiring that the C4I systems of multiple services work together effectively. Both the generally unpredictable nature of military contingencies and the wide range of non-traditional operations mean that forces and weapons are likely to be combined in novel, unanticipated ways to meet operational requirements and that their C4I systems may need to interoperate in ways not explicitly planned for in advance. Also, the new operational emphasis on rapid force projection, and the concept of early entry to halt an invasion, mean that there will likely be less time during a deployment to fix interoperability problems. Finally, the increasing size of the area over which combat operations take place—and thus the number of possible forces and weapons that must coordinate their attack—means that data is increasingly being exchanged between sensors, weapons, and systems that previously operated in a stand-alone manner. To meet such operational requirements, the different elements of the C4I system of systems will need to be more interoperable.
Many important military missions require a high degree of interoperability to support cross-service collaboration. Some specific instances in the area of joint operations include the following:
- Close air support, which requires that Army ground troops be able to communicate their air support needs to Air Force ground attack airplanes in a timely and accurate fashion;
- Suppression of enemy air defenses, which in general requires the coordinated use of missiles and aircraft operated by multiple services;
- Theater missile defense, where, as noted above, data may be shared between weapons systems of different services or shared at the joint task force command and control systems level (or higher);
- Regional air defense, which requires the coordination of many air defense assets, from missile batteries and radar on the ground to airborne surveillance platforms and air defense fighters; and
- Deep-strike attacks and interdiction of enemy forces behind the front lines, which both require the coordinated use of airspace, strike aircraft, ground- and sea-based missiles, and long-range artillery.
There is also ample evidence from experience that inadequate interoperability can cause major problems and significantly reduce military effectiveness. A recent report by the Secretary of Defense noted that ''from Grenada in 1983 to Operation Desert Storm in 1991, joint operations have been hindered by the inability of forces to share critical information at the
- During Operation Urgent Fury, the invasion of Grenada, the Marines and the Army Rangers could communicate only through offshore relay stations, because their use of radio frequencies was uncoordinated. As a result, the Marines did not know in one instance that the Army Rangers were "pinned down without adequate armor."6
- During the Joint Warrior Interoperability Demonstration in 1996, problems associated with network configuration did not support "timely interoperability" with coalition forces. According to the Joint Warrior Interoperability Demonstration report, limitations of the multilevel security systems, which were intended to allow information to be delivered to coalition forces, required manual intervention even for use of simple applications such as e-mail. This need for manual intervention "made it extremely difficult to conduct U.S./coalition collaborative planning since information . . . was never fully synchronized for both U.S. and Allied planning requirements."7
- According to the General Accounting Office, 43 "significant interoperability problems" associated with 15 C4I systems and weapons, such as the AEGIS and Patriot systems, were identified by the Joint Interoperability Test Command during four joint exercises held in 1996 and 1997. These interoperability problems, most of which "were caused by
William S. Cohen. 1998. Secretary of Defense Report to Congress: Actions to Accelerate the Movement to the New Workforce Vision, Department of Defense, Washington, D.C. This report also tasked a study to develop an improved, cross-service process for developing joint capabilities.
The Joint Interoperability Test Center of the Defense Information Systems Agency is responsible for testing and evaluating C4I acquisitions and systems, as well as identifying and solving C4I interoperability problems. As part of its work, it compiles the quarterly compilation of lessons learned, which addresses "C4I interoperability problems/issues related to Joint/Combined C4I and integration of information systems within the Defense Information Infrastructure." For additional information, see the Joint Interoperability Test Center home page at <http://www.jitc.fhu.disa.mil>.
Col. Stephen E. Anno and Lt. Col. William E. Einsphar (no date). Command and Control and Communications Lessons Learned: Iranian Rescue, Falklands Conflict, Grenada Invasion, Libya Raid, Air War College Research Report No. AU-AWC-88-043, Air University, United States Air Force, Maxwell Air Force Base. Information can be obtained through the Joint Electronic Library at <http://www.dtic.mil/doctrine/jel/research_pubs.htm>.
Defense Information Systems Agency (DISA). 1996. Joint Warrior Interoperability Demonstration 1996 Report, Defense Information Systems Agency C4I Modeling, Simulation and Assessment Division, DISA, Arlington, Va.
- system-specific software problems," could potentially "result in the loss of life, equipment, or supplies."8
In short, interoperability is essential to operability—that is, forces cannot operate effectively without a high degree of interoperability among their systems. Unfortunately, interoperability is often treated as a potentially desirable but nonessential, element of C4I programs, and a sufficient degree of interoperability, especially inter-service, is not currently seen by managers as a pass-fail criterion for their programs. Consequently, interoperability requirements tend to be one of the first things sacrificed when budgets force program cost reductions.
That said, universal interoperability is neither achievable nor necessary. Not every C4I system on the battlefield needs to interoperate with every other one. Nor is universal interoperability—which might be thought of as allowing all information in all systems to be seamlessly exchanged and interpreted—technically feasible, given the rate of change in both technologies and missions. The importance of achieving interoperability, determination of what and how much is sufficient, and decision making about allocation of resources to achieve interoperability can be addressed only in an operational context.
2.1.3 Dimensions of Technical Interoperability
On a digital battlefield, sensors generate bits, communications channels transmit bits, computers process bits, commanders act on information represented as bits, and weapons are directed by messages composed of bits. These bits are the underlying electronic representation of data and information, and to be used they must be interpretable according to some agreed-upon definitions. For two C4I systems to effectively interoperate, they must be able not only to exchange relevant bitstreams but also to interpret the bits they exchange according to consistent definitions—merely providing information in digital form does not necessarily mean that it can be readily shared between C4I systems.
Interoperability also requires that systems are interoperable at the data level—that the format and semantics of the data are also coordinated so as to permit interoperation. One significant instance where this requirement arises is in the exchange of geographical coordinates. To launch
a missile against a target, it is necessary to know the location of the missile launcher as well as that of the target. The specification of a location implies the existence of a common coordinate system (and hence a model of Earth) within which both target and launcher locations can be specified. Obvious difficulties can arise if the locations of the target and launcher are specified with respect to different Earth models. If the sensor and launcher are not using the same Earth model, a transformation of the sensor-reported location of the target into the launcher's coordinate system will be necessary. Since it has only been relatively recently that the idea of using non-co-located sensors for fire control has become practical, the implicit assumption of identical Earth models for target and launcher may well not be a valid one. Section 2.3.4 discusses some approaches to the data interoperability challenges.
Thus technical interoperability places detailed demands at multiple levels, which range from physical interconnection to correct interpretation by applications of data that is provided by other applications.
2.2 Why Achieving Interoperability Is Difficult
2.2.1 Challenges Common to All Large Enterprises
Experience in the private sector suggests that the following factors (among others) often operate to inhibit or slow achievement of desired system interoperability.
Tension Between Immediate and Future Needs
Operational units (in the DOD context, the CINCs as the warfighting authorities) in an organization often have a perspective very different from that of the planning units (in the DOD context, e.g., the Office of the Secretary of Defense, Joint Chiefs of Staff, and the service chiefs as the policymakers, allocators of resources, and providers). Operational units are concerned with the capabilities of today's systems in the short term, whereas planning units are concerned with the capabilities of tomorrow's systems, over the longer term.
- For the planner, interoperability is a capability that must be designed into a system. For the operator, interoperability is often achieved by working around problems, e.g., deciding what parts of a system to use or not use, creating patches, and modifying policy or doctrine associated with its use.
- For the planner, changes in system capability (i.e., changes in feature and function) are important. To the operator, changes in operating
- capability (perhaps enabled by changes in deployed system capability) have greater significance.
- For the planner, operational doctrine and tactics are driven by what can be imagined when the force is fully equipped and the new technology or system is deployed. For the operator, they are driven by deployment (perhaps partial) of a system and the resulting capabilities of the unit.
Large organizations recognize that operational considerations (e.g., training, doctrine) must be an integral part of system acquisition. But maintaining such a focus is difficult when operators believe (with some justification) that planners are not rapidly responsive to their immediate needs, and the planners believe (with some justification) that an overemphasis on immediate needs will not enable operating units to fully realize the benefits of new capabilities.
Tension Between Local and Global Needs
Optimizing overall system performance requires a full understanding of the trade-offs entailed by different choices. However, individual units within an organization, especially those that seldom interact with other units, are strongly motivated to solve their own pressing problems, even if doing so makes it harder for them to interact with other units. In addition, the fact that many acquisition programs have very long time lines increases the pressure to deploy independently developed solutions. The most likely result of such independent development is a patchwork of systems that are even less interoperable.9
Inability to Anticipate All Relevant Scenarios for Use
Many of the most common applications of information technology today were unanticipated when the technology was initially deployed. For example, when the ARPANET (the forerunner of the Internet) was first deployed, e-mail was considered a secondary application, whereas email is today one of the most often used Internet applications. In general, it is difficult to anticipate in detail how information systems will be used—a difficulty that is multiplied in an uncertain environment. For example, a
task force that responds to an operational contingency will usually include units that are drawn from multiple services and that have not trained or fought together in the past. Achieving flexibility in such a situation depends heavily on building in a sufficient degree of interoperability. On the other hand, interoperability does not come free. Explicitly adding pairwise interoperability between specific systems that need to work together may be in some cases cheaper or faster than building every system according to a high-level design for interoperability. And there are also possible performance trade-offs; the high-level design may not be locally optimal. Given these trade-offs, it is a large challenge to define the minimum number of instances where interoperability is imperative, and to estimate the incremental value of increased interoperability.
Development of Component Systems by Different Organizations
Different parts of a system of systems are likely to be built by separate parts of the overall organization. For example, parallel efforts are employed to reduce overall development time. Since each organization has a tendency to optimize the solution to its part of the problem, a certain degree of stovepiping—the building of systems that support only some parts of an enterprise and fail to integrate across enterprise units—is the likely result even when all parties have the best of intentions.
Inclusion of Legacy Systems
Legacy systems are in-place systems that are relatively old and were not designed to be easily integrated with current and future information systems, but which remain absolutely essential to the functioning of the organization. Furthermore, they often represent significant investment, so that replacing them with new, more interoperable systems is not a near-term option.
Managing in the Face of Rapid Technological Change
Because the underlying information technologies will certainly improve significantly over the lifetime of a system's development and deployment, it is desirable to plan for the incorporation of these improvements during the later phases of system deployment. Systems designers must thus pay particular attention to two areas:
- Sustainability of the technological environment selected. Technology selection and migration strategies have significant implications for inter-
- operability. Initial choices of technologies from which systems will be built have long-lasting consequences, because they in effect freeze an enterprise's infrastructure. But because the information technology industry is so dynamic, even broadly accepted technologies may later be abandoned by the marketplace. As a result, for example, a company that 10 years ago had selected CP/M as its basic operating system would have had to convert long ago in order to remain current. Because maintaining interoperability with systems based on an abandoned infrastructure is in the long run a very expensive task, developers forced by circumstance to develop applications in an obsolete (or soon-to-be-unsupported) technological environment must also have migration strategies to port their applications to a more sustainable environment. On the other hand, the very latest technologies are not always the best choice; to maximize the likelihood of maintaining interoperability, it is prudent to select relatively stable technologies that are achieving widespread adoption and are likely to enjoy longer-term support.
- Backward compatibility. To at least minimally protect users' investments in design, applications, and training, and provide at least a limited measure of interoperability across versions, commercial information technologies usually incorporate considerable backward compatibility from generation N to generation N + 1, and usually provide tools to facilitate user transition to the newer generation. However, support for backward compatibility is not unlimited, and at some point, support for the earliest generations is usually abandoned. (Thus, generation N - 3 may no longer be fully supported.) Indeed, given the rate of evolution of the processing and storage capabilities of the underlying commercial technologies—and the advances in applications that these improvements enable—it is unrealistic to maintain backward compatibility forever. Management must provide guidance to system designers for how long backward compatibility is to be maintained and indicate a strategy for defining, batching, and sequencing system upgrades. In general, configuration control is required to provide operationally required interoperability and minimize deployment and training costs. The problem is made more difficult when the rate at which enterprise-wide upgrades take place is much slower than the rate of progress in the underlying technology (for further discussion in the DOD context, see section 2.2.2).
Heterogeneously Equipped Organizations or Units
Large organizations usually stage the rollout of new generations of technology or applications over a period of time, either to shake out problems before a full deployment or because limitations on budget or other resources such as training do not allow the deployment of a new genera-
tion all at once. In all of these instances, the systems deployed must have interfaces that allow some degree of backward compatibility so that they will be able to exchange data. In addition, policy or doctrine must deal with the need for units equipped with new generations of technology to interact with others not comparably equipped (the issue of how to address this question in military doctrine is addressed in Chapter 4).
Use of off-the-shelf products and subsystems built to commercial standards can reduce costs and development time and can make interoperability easier to achieve. (Box 2.3 describes how commercial standards are established and the basis for their staying power.) A good program definition will have clear criteria for when the use of commercial off-the shelf (COTS) products is appropriate. Because contractors may be motivated to avoid COTS products to maintain account control and differentiate themselves in the marketplace, incentives are required to ensure the use of COTS products when appropriate.
Inadequacies of Existing Commercial Standards
Of equal importance to the appropriate use of COTS technology is the establishment of clear criteria for when its use is not appropriate, or at least for how difficulties arising through its use will be addressed. Such criteria are required to address security problems that arise in many uses of commercial products such as off-the-shelf operating systems. Another example of the inadequacies of commercial standards is the problem of using Open Shortest Path First routing in an environment where the "shortest path" routing algorithm may yield undesirable results, such as when mobile, low-capacity routers become the shortest path in a battlefield.10
Controlling System Requirement Creep
It is the normal behavior of vendors to try to offer some unique perceived benefit over their competitors. If these benefits take the form of
BOX 2.3 The Development of Commercial Standards
Commercial standards are set in two primary ways. One method relies on the development of a consensus among private firms, technical experts, customers, and other interested parties. For example, the Internet Engineering Task Force helps to develop the consensus on many of the standards for the Internet. A number of consensus-based standards-setting bodies follow consensus standards development procedures promulgated by the American National Standards Institute. These procedures include open participation of volunteer technical experts in standards-writing committees; consensus agreement among committee members in support of any proposed standard; and elements of administrative due process, such as opportunities for comment and voting by affected parties.
A second approach to standards development in the private sector relies on marketplace competition. When one firm's product achieves a high degree of dominance In the marketplace, its specifications become a de facto (or industry) standard. A variant on the creation of industry standards is their promotion through industry consortia. Examples of such consortia include the Object Management Group and the World Wide Web Consortium. De facto standards largely characterize the world of information technology and communications networks. Indeed, networked computers and communication devices are of little value if they are based on a standard that few others use—there is no one to communicate with. Thus, increases in the number of devices conforming to a standard lead to greater pressure for other devices to conform to that standard.
Both approaches have in common the fact that they are—to varying degrees—supported by either the marketplace and/or a broad base of vendors and customers. This base of support helps to ensure that products incorporating commercial standards will continue to be built and purchased, thus reducing the chance that products will be "orphaned."
None of the above discussion should be taken to imply that commercial standards have no downside. Standards may freeze technology prematurely. User commitments to the use of a prematurely established standard and a hard-to-change infrastructure can then restrict the development and deployment of new and more useful technologies. Moreover, a standard that is popular in the marketplace may not necessarily be the most appropriate for all end-user applications. Nevertheless, it is safe to say that standards have on balance facilitated rather than retarded the growth of the information technology industry and the rapid pace of technological development
SOURCE: Adapted from National Research Council. 1995. Standards, Conformity Assessment, and Trade, National Academy Press, Washington, D.C.
additional system features, components incorporating those features may create additional complications for interoperability. Users must not allow suppliers to drive the system requirements so that they can differentiate themselves. Suppliers must be convinced that they have more to gain by conformance to a common architecture than they have to gain by product differentiation.
Difficulties of System Integration in Complex and Critical Deployed Systems
Systems integration in the DOD environment poses particular difficulties in at least two instances. The first is the need to integrate a large number of components. Since both the components and their specifications are usually incomplete, systems integrators have to discover what combinations of components (down to the specific version or release number) can interoperate successfully. The number of such rules grows much faster than the number of components. A second difficulty is integrating into an operational system that cannot be taken offline. In the absence of systems that replicate essential elements of the operational system, all integration testing must be performed on the operational system, which places many constraints on the changes that can be made. Even in the civilian world, an industrial laboratory is sometimes used to reproduce bugs that are exhibited in a particular customer configuration. One cannot take over the customer's mission-critical systems to do testing; it has to be reproduced in a separate test facility. Similarly, one cannot stop a war to debug the C4I systems. Resolving faults that occur in an engagement often requires offline resources for debugging.
Synchronization of Interdependent Programs
In many large deployments, a number of independently developed components must be brought together to work as a whole. If two systems are to be pairwise-interoperable, design decisions in one program may have an effect on the other program. If the first program is significantly delayed, the other program may have to proceed without those decisions being made, with the likely result that interoperability in the end may be adversely affected. The alternative is delaying the second program, a highly undesirable outcome. Thus, the time lines for developing these components must be synchronized if interoperability is to be effected in a timely manner. Such synchronization refers not only to product delivery at the proper times, but also to matters such as timely decision making and testing within each program so that decisions are made that facilitate interoperability and problems uncovered soon enough to not cause additional difficulties later.
2.2.2 Special Challenges Faced by the Department of Defense
All of the factors described in section 2.2.1 are challenges faced by the DOD. In addition, the unique mission of the DOD poses challenges beyond those typically found in the civilian sector, including the following.
As noted above, it can be safely predicted that over the lifetime of various C4I systems now and yet to be fielded, some operational scenarios will call for the use of these systems in ways that cannot be anticipated today. Requirements for interoperability of C4I systems, as well as the C4I embedded in weapons and sensors, cannot always be fully anticipated in advance.
Many weapon and sensor systems were designed to operate in relatively loose coordination with other systems. Today and in the future, these weapon and sensor systems are intended, and will be expected, to operate much more cooperatively, thus placing more stringent demands on C4I systems. Moreover, the flip side is also true: as new C4I capabilities become available, a weapon or sensor system should be able to exploit them.
Unforeseen C4I linkages also arise when old weapons systems are given new missions. For example, a nuclear delivery system such as the B-1 bomber may be assigned to conventional bombing missions with substantially different C4I requirements. In this case an interoperability problem is created at the physical layer (Box 2.4); the B-l, originally designed for strategic nuclear missions, cannot receive digital downloads of information that would enable it to retarget weapons while in flight. A second example is that the Patriot missile system, originally deployed for defense against aircraft, is now used as a defense against theater ballistic missiles.
C4I systems may also find new uses. For example, the Joint Surveillance Target Attack Radar System—originally acquired to serve Air Force and Army needs for ground surveillance—is now viewed as important to support Navy land strike missions.
Finally, in the course of using C4I systems in both exercises and deployments, users will often find a need for one system to interoperate with another when that need was not explicitly anticipated at the design stage of either system. Despite the best intentions and early planning of C4I system designers, there are likely to be many cases where user needs surpass those envisioned by the authors of the original requirements.
In all of these cases there is a need for architectural efforts across systems aimed at accommodating future unanticipated interoperability requirements.
BOX 2.4 Layers in the Open Systems Interconnection Reference Model
In the area of communications, the Open Systems Interconnection reference model1 provides a useful framework for thinking about different levels or layers at which interoperability must be considered for C4I systems.
Deployments Are Typically Conducted on an Ad Hoc Basis
Under today's arrangements, assembly of forces for contingencies is ad hoc, based on a generic set of requirements rather than preplanning that designates specific forces for a particular contingency. The number of possible force combinations that might be employed and for which interoperability must be tested, exercised, and established to meet the contingency is thus larger than would be the case if they were at least in part predesignated. This complexity also increases the difficulty of assessing the interoperability component of the readiness of forces that might be called on for a given deployment.
Operations that involve coalition partners impose special challenges to achieving interoperability. With countries in a formal military relationship with the United States, such as North Atlantic Treaty Organization (NATO) members, there is an established framework in which to work on interoperability challenges. Absent a formal treaty relationship, as was the case with non-NATO coalition partners in the Gulf War, or when it is less predictable who the coalition partners will be, it is far more difficult to deal with interoperability challenges in advance of an operation conducted with a coalition partner. In both cases, but particularly in the less formal coalitions, the U.S. partners will not necessarily have adopted the same set of standards—even commercial ones—as those used by the United States. A final challenge is that coalition partners in both classes typically spend less than the United States on modernizing their C4I systems and thus may well be using equipment that is substantially less capable than and incompatible with present and planned U.S. C4I systems. The introduction to the recommendations in this chapter and section 4.3.4 in Chapter 4 discuss these and other challenges of coalition warfare for C4I systems.
Flexibility to Accommodate Variations in Command Structures
Command relationships determine the overall nature of information flows, and joint task force and theater commanders have the discretion, and the responsibility, to determine these command relationships as they think best. Commanders who choose unconventional command relationships may well require C4I linkages that have not been attempted before. New C4I linkages are likely to be required both on a large scale whenever a joint task force is deployed, as well as on a smaller scale even in an established theater (e.g., Korea) that receives new units or forces.
Flexibility to Accommodate Changing Tactical Situations
C4I systems need to be able to be reconfigured, augmented, and redeployed as the tactical situation changes and the various C4I components fall under attack, are required to support multiple operations at the same time, or are otherwise placed under stress.
Short Configuration Times
Particularly stressful are operations that are short-notice, ''come as you are" events (e.g., Grenada). Here the requirement is that C4I interoperability be achieved within hours or days, rather than the weeks or months typically available in the commercial sector. Especially in operations when little time is available for field integration, interoperability limitations among C4I systems impose limitations on how systems can be connected and thus may impose undesirable constraints on what command linkages can be implemented.
Long Cycle Times for Complete Upgrades Leading to Heterogeneously Equipped Units
DOD procurement budgets usually make it infeasible to deploy a given generation or version of technology widely before that technology increases significantly in capability. Such budgetary limitations have two significant consequences:
- Because the time needed to equip an entire service is long compared to the time scale on which information technology changes (e.g., processor power improves by a factor of 10 in 5 years, but it takes on the order of 15 years to fully equip the Army with modernized tanks), the technology underlying a new C4I system will be much more capable at the end of the procurement cycle than in the beginning. Backward compatibility of new generations with preceding generations thus becomes an important issue to resolve.11
- While a new C4I system is being installed, and perhaps throughout the system fielding cycle, different units may have different capabilities.
As discussed in section 2.2.1, backward compatibility is supported in the commercial sector for only a limited number of generations. Such practices are reasonable in the commercial world given the rate at which users are upgrading hardware. Whether the same time scales should govern military acquisition of C4I systems is less important than the underlying point—at some point determined by the underlying information technology (and not by the C4I system of which it is a part), compatibility efforts may have to be abandoned and incompatible upgrades may prove to be essential.
The division selected to be first equipped may have Version 2 of a system, while all others have Version 1. Or, the initial division will have Version 1 (as will happen in the Army's digitization effort), while the others have nothing. Then too, a given contingency may require digitized and non-digitized divisions to work together. These interoperability requirements—compatibility in doctrine, tactics, training, and ability to exchange information with non-modernized units—place many constraints on modernization efforts.
In short, the C4I systems in use in the individual services will not, and cannot, stay in lockstep. Thus, even a "perfectly interoperable" information system would not solve the problem permanently. The rate of change of both technology and warfare would ensure that such perfection would be at best transitory.
Building Horizontal Systems in a World of Vertical Organizations and Programs
Although the goal for many C4I systems may be that they be interoperable in a joint environment, this horizontal objective must be realized in a world that is fundamentally vertical. The vertical focus of system acquisition comes from two major sources. First, C4I system components are typically acquired by the services and funded out of service budgets. Second, the acquisition system itself is geared toward the development and procurement of discrete components rather than system-wide capabilities. Program managers are generally held accountable for the performance, cost, and schedule of their piece of a system, not for the performance of the whole system of systems.
2.3 Technical Approaches To Interoperability
As noted above, all large organizations have trouble achieving interoperability. As a practical matter, large organizations are generally not able to start with a blank slate with their information systems. In other cases, enterprises that are reengineering across a range of business practices, or that are restructuring operations, will introduce major new systems.12 In both instances, it makes sense to strive for an information systems environment—perhaps never fully realized in practice—that is based on a clean architecture and requirements specification, common data structures, common interface requirements, and well-specified high-level
information flows. Systems constructed in accordance with such an architecture are much more likely to be adequately interoperable than those that are not.
Architectures are a hierarchical description of the design of a system and in many cases how it will be developed, evolved, and operated—"the structure not only of the system, but of its functions, the environment within which it will live, and the process by which it will be built and operated."13 Architectures provide the underlying blueprint for the more detailed design and implementation decisions about components of a system. When well-defined architectures exist, engineers can design individual components and builders can implement them with a high degree of confidence that the end result will work as expected and meet user needs. Successful architectures are driven by more than technical consideration—they have as their fundamental goal the support of the requirements of users throughout an organization and are often represented in multiple dimensions, e.g., functional views, physical views, and operational views. When done well, architectures have enormous influence on the success of the overall endeavor. Some examples of commercial information systems architectures that have had such impact are the Ethernet local area network, the IBM S/390, and Digital's VMS.
Within an organization, development of architectures goes hand in hand with business process reengineering. In the military context, such business process reengineering would translate to an examination of how doctrine and procedures might evolve to exploit new capabilities offered by C4I systems (see also section 4.1.4). The mere automation of existing processes results not only in less-than-optimal gains, but also in "islands" of functionality (determined by the preexisting business processes) that exchange information only with great difficulty. Because reengineering requires an understanding of information flows that cut across old organizational boundaries, it lays the intellectual groundwork for an architecture that will support those flows.
2.3.2 Interfaces, Layers, and Middleware
Systems that perform a variety of functions are normally composed of multiple subsystems or components. Interfaces arise whenever one com-
ponent or subsystem needs to interact with another. Principles for the partitioning of systems and selecting interfaces include:
- Managing modular development. Partitioned system design with well-designed interfaces permits development programs to be divided into more manageable pieces, which in turn can result in faster development because the work of different players can proceed in parallel. When it is desired to spread system development across different operating units, this approach is essential.
- Permitting modular change—in versions and implementation technology . By encapsulating the internal details of a system component (which may change over time), interfaces allow changes in internal implementation of portions of a system to be transparent to other portions. Interfaces thus permit various parts of the overall system to evolve over time without requiring changes to be made simultaneously throughout a system—allowing components to be upgraded as technology evolves and user needs mature.
- Reducing the number of interaction points between systems. Reducing the complexity of intersystem dependencies facilitates more rapid reconfiguration of systems to meet operational requirements. The modular decomposition of systems often is both horizontal and vertical. Vertical decomposition refers to interfaces between discrete systems within the same layer—for example, a standard message format used by two different applications to exchange information. Horizontal decomposition of functions in an architecture—for example, the separation of bit transport technologies, transport protocol, and applications—is known as layering.
Layering can do a great deal to facilitate making C4I systems interoperable in the presence of rapidly changing technologies and multiple technology choices. Layering makes it possible to design a system of systems that has technology independence, scalability, decentralized operation, appropriate architecture and supporting standards, security, and flexibility, and can also accommodate heterogeneity, accounting, and cost recovery.14 When layers in a system are identified, it is important to realize that layers that correspond to widely adopted standards are likely to be the most successful. The wide popularity of the Internet and the prolif-
eration of Internet applications are evidence of the power of this principle. Specific examples include:
- The use of TCP/IP to decouple communications link technologies from applications that use communications. A diverse, rapidly changing set of link-level communications technologies (ranging from analog telephone circuits to wavelength division multiplexed optics) is thus separated from an even more diverse set of applications. System designs based on this layering principle produce applications that can interoperate with each other through networks built from a variety of technologies.
- The use of hypertext transport protocol (HTTP) and hypertext markup language (HTML) to separate presentation from storage and retrieval functions. Presentation on a variety of client platforms is separated from a rapidly evolving, wide variety of server-side applications and functions.
Middleware is one instance of the layering principle. It provides a separation between applications and the operating system platforms that the applications run on. By decreasing the dependence of applications on a particular operating system, middleware increases the ease of moving applications to new computer systems and decreases dependence on operating systems that might fall out of favor in the commercial marketplace.
Middleware has an additional dimension—as a toolkit, it provides a set of relatively high-level common functions that are used in common among applications, and permits applications to be built out of building blocks. Examples of functions that can be provided by middleware are file system support, privacy protection, authentication and other security functions, tools for coordinating multisite applications, remote computer access services, storage repositories, name servers, network directory services, and directory services of other types. 15 Thus middleware offers two additional advantages. First, when common software is used to provide particular functions, interoperability is more easily achieved. Second, by increasing software reuse, middleware can reduce development costs.
A key element of architecture is the establishment of technical standards. Such standards define common elements, such as user interfaces,
system interfaces, representations of data, protocols for the exchange of data, or interfaces accessing data or system functions. Examples of standards include UNIX, Windows, TCP/IP, structured query language, and the Defense Information Infrastructure-Common Operating Environment. Technical standards offer a number of advantages for a system architect:
- They make it easier to exploit changing technologies (Box 2.5). For example, standardized interfaces facilitate interoperability because a component that conforms to a given standard can "plug" into a standard interface without concern for how the component on the other side of the interface works internally.
- They provide an understanding of data or a platform that is common to all component developers.
- They facilitate interoperability because they are accepted by multiple vendors and thus increase the likelihood that a collection of systems from diverse sources will be able to interoperate.
As advantageous as standards are, an approach to interoperability based on standards and/or standards-compliant common products must deal with certain realities and issues:
- In some areas, capabilities or services of interest are not covered by standards, although de facto standards, instantiated in broadly used products, can be an attractive option.
- In other cases, there are standards but no existing, mature products (e.g., standards "holes" in functional areas or relative to features such as security).
- Even when there are accepted standards and products compliant with these, interoperability is facilitated but not assured; there are options within standards, different releases and versions of products, and so on. The devil of assuring interoperability is in the detail of implementation. For example, the definition of an interface standard might not specify allowed and disallowed sequences in which a connecting component may call on different system functions. Thus, a component that issues a particular sequence of calls may cause a malfunction in the other component if that sequence was not properly anticipated. Vendors may also add additional capabilities or features to distinguish their products from those of their competitors; systems that rely on these features may not interoperate with systems that more closely follow the standard.
- There is a natural tension between adopting standards and taking advantage of the continuing stream of improved capability offered by technology, now dominantly driven by the commercial marketplace.
- Finally, it is important to realize that technical standards are, by themselves, necessarily incomplete from the standpoint of a system or
BOX 2.5 Interface Standards and Rapid Exploitation of Technology
Information technology is characterized by rapid change. How can such change be exploited by the system designer?
One approach to technology exploitation is to rely on standardized interfaces so as to avoid the need for tight "vertical" integration of system components. Consider, for example, a system consisting of a set of sensors providing input to a set of databases, on top of which is built a system providing data integration, analysis, and decision support. Progress will be made in both the front-end sensor technologies and in the (mostly commercial-off-the-shelf) technologies supporting the back-end analysis and decision support, but this progress may be made at very different rates. Particularly in time-critical applications, it may be the case that frequent upgrades to specific functional capabilities in decision support could pay huge dividends. When care is taken to establish a well-defined interface between the sensors and the databases, and another interface between the databases and the decision support tools, different parts of a system can develop at different rates independently of each other.
It is true that designs that rely on standardized interfaces cannot take advantage of special characteristics of the components themselves, with the result that an interface-based design may have poorer performance in some dimensions (e.g., speed, bandwidth) than a tightly integrated one. Tight integration historically has characterized military systems. For example, in the Joint Tactical Information Distribution System the message formats, the waveforms, and the hardware are highly intertwined. But in addition to not allowing exploitation of all of the good properties of layering (e.g., minimal interaction between layers and thus greater ease in "debugging"), such an approach ignores the fact that a tightly integrated design must—by assumption—proceed at the slowest development pace that characterizes any of its components. In a world in which the underlying technologies evolve so rapidly, the performance benefits of tight integration come at the cost of not being able to use new technology as it becomes available—on balance, a losing proposition.
Well-defined interfaces also enable the creation of reasonably accurate system models for use in optimizing a system and understanding the performance enhancements that will result from specific localized upgrades.
- component designer. The important thing is the operational scenarios that a system is expected to support. This range of scenarios defines the context in which a system is to perform specific desired functions and thus provides a meaningful reference for testing and evaluation.
As a general rule, some standards gain widespread acceptance in the commercial computer and communications industries and thus tend to
have a long lifespan. The marketplace tends to weed out weak standards before they become widely accepted. And once a standard is widely used, industry is often motivated to maintain compliance with this accepted standard. Standards created by niche players in the market tend not to survive.
DOD, despite its size, is a small force in the overall marketplace, which suggests that if DOD attempts to create its own standards, the standards will not be viable in the long run except where they are relevant only to military applications and do not have to compete with analogous standards in the commercial sector. DOD is more likely to be successful if it exploits well-articulated and tested commercial standards wherever possible in C4I systems. An example is the use of TCP/IP. Although TCP/IP lacks certain features that would be helpful in the military environment, it is widely and successfully used by DOD. Even in those cases where today's commercial technology is not sufficient to satisfy DOD needs, a DOD-specific development is not necessarily justified. It can also be useful to project where commercial technology will be, in terms of its capabilities, in the time frame in which a DOD-specific product would realistically become available.
However, deficiencies in the security of many commercial technologies represent a special case and deserves special attention (see Chapter 3). Frequently, the best approach is to accept an 80% compromise solution (see section 4.3.2 in Chapter 4) that meets the bulk of DOD requirements.
When essential capabilities are missing from a standard, the best approach to dealing with the shortcoming is to either work to extend the standard or develop extensions to the standard. Because the use of commercial standards is such a powerful tool for ensuring ongoing interoperability, supportability, and upward evolution, designers may be well advised to use such standards even when they may lack certain features. If the lack of certain features is critical, then a custom development or an effort to have such features included in the commercial standard may be necessary. In other cases, work-arounds may be possible that enable the final product to meet the vast majority of its functional requirements. Program managers must have both an explicit strategy for developing such work-arounds as well as a credible analysis that indicates that the use of a commercial standard is tolerable. Section 4.3 discusses approaches to the use of commercial technology.
2.3.4 Data Interoperability
Experience suggests that left to their own devices, the designers of individual systems will often make locally optimal decisions about data
definitions and formats. Data formats resulting from such local decisions may not be compatible when operational requirements dictate that a network of systems be called upon to interoperate. For example, different applications might use the same field code to mean different things, thus leading to interoperability problems among the applications. Thus architectural design must provide guidance to developers to minimize the applications-layer incompatibilities that inevitably arise when systems with different purposes must communicate with each other.
Examples of approaches to data interoperability include:
- Single data definition for all systems. Mandating a single data definition for all systems is conceptually appealing. However, it is dangerous for several reasons, especially when applied on a large scale to a complex, evolving system (or system of systems):
- Across a large organization (in which subunits have different needs and view the same concepts differently), it is a very difficult task to agree on definitions. The definitions that emerge are likely to have mistakes. Other approaches also may result in errors, but because their scope is limited, the errors have limited consequences.
- The task of agreeing on definitions consumes a great deal of effort and time that might be better used elsewhere. Waiting until agreement is reached may be very costly.
- Even assuming that a single set of data definitions can be developed for a set of applications, it may well be difficult to design a new application around those definitions. And developers of later applications do not have the benefit of having helped to develop the initial definition.
- When a single set of definitions is mandated for all applications, definitions are no longer locally optimal, and thus such mandates often encounter substantial resistance in implementation.
- Object orientation. A technically promising approach is to use object-oriented concepts to develop data definitions, encapsulating the internal details of the data. A change in the representation or definition of the data then has minimal impact on the applications that access that data. Contrast this with a linear record that defines some data object—the result is that all the applications that access the data are subject to change when any changes are made in the record.
- Extensible data model. Another approach to achieving data interoperability uses an extensible data model and standardized interface. The Simple Network Management Protocol is a good example. It has a generic description of types of objects that can be extended by applications
- without requiring universal agreement on the extensions. This approach allows new devices to interoperate with the rest of the network management system.
Legacy systems, which have been built around frequently unique data definitions, pose a major challenge to interoperability. Industry has developed a number of approaches by which systems not designed up-front for interoperability can interoperate to exchange information:
- The data "bus" approach. Each system uses its own data definitions internally. However, exchanges of data with other systems are conducted through a "bus," that is, a common data standard into which data must be translated before being transmitted to another system. Any system wishing to use this data then downloads it from the "bus" and retranslates the data into locally meaningful terms before that data is used.
- The data dictionary approach. Each system has a published data dictionary and a simple query-response mechanism to access the data with published message formats. Given a later need to interoperate, another supplier could build to that embedded base interface and access the system's data. A system with this capability may cost marginally more than a closed system, and additional security issues need to be addressed, but it is often a reasonable poor-man's approach to interoperability when nothing better exists.
- The data translator approach. Two systems that need to interoperate have a translator that converts one set of data definitions into the other. This approach preserves the internal integrity of a legacy system, but the translators may be slow and, more important, may not preserve the original semantics of the underlying data.
- The data server approach. Data and processing are separated. When a system requires data, it connects to a data server that provides the data. Thus, enforcement of definitions can be limited to just a few servers rather than a myriad of applications. By moving the data into a system separate from the individual applications, this approach facilitates reuse of data in new, unanticipated ways.
2.3.5 Developing and Implementing Architectures
Commercial best practice suggests the following principles for developing and implementing architectures.
Use a Small Architectural Team
A critical element of developing a good architecture is the involvement of a good architect. The role is demanding, requiring an ability to
balance needs and resources, technologies, and the interests of multiple stakeholders. As a general rule, good architecture results from a small number of people (perhaps a single chief architect, perhaps a small, closely knit team) being responsible for its content and structure. Architecture is both an art as well as a science, and a good architect must rely in part on aesthetics. Good architectures are less likely to emerge from large teams or from a broad consensus-based approach because the search for consensus almost always results in unwieldy compromises that have negative effects on system building. Consensus architectures are likely to lack a clear design philosophy, which often causes confusion among implementers.
Position the Architect Appropriately Within the Organization
Developing an architecture is an endeavor that touches on units throughout an organization, and care must be taken to position the architect. To maximize the chance of success, the architect must:
- Not be owned by any subset of the organization,
- Have the support of the top leadership,
- Have an appropriate charter and sufficient authority, and
- Have sufficient technical resources.
Limit the Scope
The perils of attempting to establish architectures over too wide a scope have been seen in a number of instances, and caution is in order in approaching C4I interoperability with a goal of a fully integrated C4I system of systems with seamless interoperability. One should not forget that the world has seen more than a few failures associated with global efforts to reshape the software landscape over a short period of time. Examples that come readily to mind include DOD's effort to establish ADA as the universal programming language (Box 2.6). The lesson to be learned is that in the hope of achieving a grand and universal solution, it is easy to grossly underestimate the complexity associated with a project of such large scale, the difficulty of managing it, and the level of talent required at all levels to achieve success. Indeed, scope must be limited for several reasons, including overall complexity, the need for scale to be commensurate with the pace of change in both missions and technologies, and the need to use small teams to develop good architectures.
Foreseeing all of the kinds of applications and their combinations is something that is both very difficult to do and often not successful. Before its breakup in 1984, the Bell System network was a good example of a
BOX 2.6 Commercial Failures Arising from Excessively Large Architectural Scope
Open Systems Interconnection
The International Organization for Standardization's Open Systems Interconnection (OSI) standards were an ambitious attempt to standardize networking protocols from the network level up. to the application level. A great many committees met over a number of years during the 1980s and early 1990s and defined standards for packet formats, transport protocols, email, directories, security, management, and many other topics. Many vendors, governments (including that of the United States through its Government OSI Profile program), and large corporations declared their intention to replace their use of various proprietary standards (such as DECnet and Novell), as well as the Internet protocols, with Open Systems Interconnection standards. But the whole enterprise came to nothing. All that remains in the market is a fragment of the X.500 directory standard called LDAP, and the X.509 public-key certificate standard. Everything else has been overwhelmed by Internet standards. Some of these, like the basic TCP/IP protocol and the Simple Mail Transport Protocol (SMTP) protocol for e-mail, had the advantage of being fielded before the Open Systems Interconnection effort started. But others, like the Simple Network Management Protocol (SNMP) and the Domain Naming System:(DNS) directory service, came along well after the corresponding Open Systems Interconnection efforts, and usually in reaction to their excessive complexity.
Originally conceived as a single computer language that would be suitable (and mandated) for nearly all DOD programming efforts from financial accounting to real-time systems control, Ada's scope grew to quite unwieldy proportions and its use was often resisted even within DOD. Responding to the recommendations of a National Research Council report,1 the DOD adopted in April 1997 a policy that eliminated the mandatory requirement for use of the Ada programming language in favor of an engineering approach to selection of the language to be used. Programming language selections would be made ''in the context of the system and software engineering factors that influence overall life cycle costs, risks, and potential for interoperability." 2 Thus, it is likely that programming languages that are more commercially viable and popular will be used to a much greater extent for DOD systems that are not associated with weapons systems or C4I systems.
fully integrated system structure.16 In this case, system integration was achieved over an extended period of time by strong top-down coordination, specification, testing, and strong management. In contrast to the public switched telephone network, however, the entire military C4I system of systems is far too complex and its missions change too rapidly for an approach of a single overall system design to be feasible, suggesting an approach to interoperability that focuses on more narrow mission areas. Overly tight integration also makes it more difficult to fall back to more independent operation when C4I systems are placed under stress.
Some would also argue that the Bell System was very slow to change with advances in technology because of its tremendous level of integration. Similar arguments can be made about the computer industry. Rapid changes in technology, cost, and features have often come about when the computer industry ceased to be vertically integrated. De facto interfaces were defined by the marketplace (e.g., instruction sets, operating systems, structured query language) that allowed intense competition and rapid, independent development on either side of an interface that no longer needed slow, centralized coordination of all of the parts of the network. Thus, it is necessary to strike a balance between striving for fully integrating systems, which brings with it a high degree of interoperability but likely will stifle quick innovation, and adopting a less constrained environment that permits faster exploitation of technological advances.
Finally, if the principle that architectural teams must be small is to be followed, the scope of the architecture must be limited. When a small team develops an architecture for a more narrowly defined operational scope, it is more probable that a well-designed architecture will result.
Engineer for Flexibility
Engineering for flexibility, so as to increase the likelihood of interoperability over time, includes several approaches discussed above:
- Bias toward use of COTS. Development of an architecture should rely as much as possible on the commercial market, and system designs should be based on compositions of COTS components. Then a substantial burden for interoperability, as well as continued development of the components, is passed to the commercial sector. Strategies for using COTS are discussed in section 4.3.3. This approach depends upon an acceptance of the "80% solution," discussed in more detail in section 4.3.2.
- Use of standards. Use of technical standards is one way of planning for the future. Compliance with technical standards is an investment that facilitates, though by no means guarantees, future interoperability. Interfaces are another investment in the future; by providing well-defined ways of accessing systems and capabilities, they facilitate components composed in new ways in the future, or new uses of existing systems.
- Investment in metadata. Another investment in future interoperability is the use of sufficient metadata to enable data collected or generated by a system to be used in future applications in ways beyond the original intent. For example, providing geo-location data along with imagery makes it easier to use the imagery in a wider variety of applications.
As argued above, an essential underpinning of C4I interoperability is architecture and requirements specification. Ensuring that the architecture and requirements are in fact successfully implemented, and that the required level of interoperability is achieved (which is not guaranteed by conformance to specifications), requires comprehensive testing and evaluation. Testing is critical to achieving interoperability and has an especially large payoff if conducted concurrently with development. Many interoperability problems are subtle, manifesting themselves only in certain sets of circumstances, and so are hard to uncover, and they demand a great deal of empirical work and testing to resolve.
Testing compares actual performance with requirements. It can take place in a laboratory, a field location, or at someone's desk with early system designs. Typically, systems are tested at different stages in their life cycle: during development, preproduction, and in the field (Box 2.7 describes DOD's efforts in these areas):
- Developmental testing assesses progress in meeting system-level requirements ranging from functionality to performance (including software stability). To ensure correct intent, a system's "paper" requirements may be tested against user-stated needs. Systems may be tested against requirements to ensure correct architecture and design. Subsystems may be tested against designs to ensure correct development.
- Preproduction testing is undertaken when a system has completed the development process but before it has been accepted for production.
- Conformance testing focuses on the stand-alone functionality and performance of a particular system. Through a paper or laboratory test, it validates the system in terms of stated requirements or specifications. The result of conformance testing typically is formal certification of compliance with the relevant standards.
BOX 2.7 DOD Testing and Evaluation
The DOD maintains an extensive test and evaluation structure that encompasses developmental and preproduction testing by the services' program offices and independent testing by designated service organizations reporting up through their service chiefs and to the Office of the Secretary of Defense's Director of Operational Test and Evaluation. The primary purpose of this testing is to ensure that a system meets specified functional and technical performance criteria and is operationally capable. The goal generally is to ensure that a system meets the requirements established for the system in its Test and Evaluation Master Plan, prior to its certification for full-scale production (as opposed to low-rate initial production) and its subsequent fielding and use by the operating forces. For C4I systems interoperability, the Defense Information Systems Agency through its joint Integration and Engineering Office and subordinate joint Interoperability Test Command performs operational test and evaluation for joint C4I systems throughout the entire system acquisition and deployment process.
Additional follow-on test and evaluation of C4I systems are also done for selected critical systems. This type of testing takes two forms. The first is a continuing test program of quantitative measures of the day-to-day operational performance of fielded systems. Diagnostic evaluations are performed to identify problem areas, and recommendations (concerning engineering or software changes, as well as procedures) are provided to address performance problems. Continuing follow-on testing and evaluation provide the operational and administrative commands a timely assessment of system operational performance and readiness. The second type of follow-on testing and evaluation for interoperability involves selected joint force exercises and tests in simulated operational environments. It provides both qualitative and selected quantitative assessments of the performance of C4I systems and is usually done at somewhat less than full scale, compared to actual operational environments.
- Today, commercial suppliers are commonly regarded as having the primary responsibility for ensuring conformance to customer's requirements, transforming conformance testing from an adversarial test conducted by the purchaser into a more cooperative process (Box 2.8)
- System-to system testing determines how well a system interoperates with other systems. It is typically performed in a laboratory, where two or more systems can be interconnected. Involving multiple systems and suppliers, it is usually more complex and expensive than conformance testing . Its scope can range
BOX 2.8 New Testing Relationships Between Vendorsand Customers
Today, testing is generally performed comparatively early in a product's life cycle, as an integral part of the development process, and is led by the supplier with input from, or even the active participation of, the users. The supplier openly shares test results with its customers, thus minimizing the need for customer-performed conformance testing.
Customers view suppliers favored in this way as strategic and often have risk-sharing financial relationships to maintain their interest, performance, and trust. Cooperative relationships often mean that suppliers understand customer needs better, time to market is shorter, and overall testing costs are lower. The disadvantage is that the customer may lose the additional level of assurance that a supplier product conforms to specifications.
Despite the power of a more cooperative testing position, this type of supplier responsibility has typically not extended yet to end-to-end performance of systems interoperating with many other systems from many other suppliers. Achieving and maintaining end-to-end interoperability are often still activities for the customer/user to manage.
An important corollary of having suppliers accept responsibility for the conformance of their systems to their customers' requirements is that this responsibility does not stop when a system is first fielded. Latent faults may not be discovered until new systems are later connected to this embedded system or the system is placed in some new environment. Suppliers practicing good quality management techniques accept the responsibility for later fixes to their systems. Their costs for performing this function either were allocated as an internal reserve of the original system purchase price or are recovered through customer-purchased "maintenance releases" of system improvements.
- from "lower-layer" (e.g., communications) to "higher-layer" (e.g., applications/data) interoperability.
- Field testing17 assesses the extent to which a system satisfies users' operational needs in a "real-world" setting, which differs from the controlled environment of developmental and preproduction testing: system configurations in the field (e.g., software releases, intermediate communications, etc.) are quite likely to be different, in detail, from the ideal configuration envisioned in the system design; those personnel operating the systems are typical field personnel rather than technically trained engineers; and nuances of system usage—often not apparent until a system is
- fielded—will arise, especially under non-ideal scenarios. Field testing is also essential because end-to-end interoperability involves critical nontechnical dimensions such as people, procedures, and training. Additional complications that require field testing to resolve may arise because corporate or organizational information systems are typically systems of independently developed systems (or components) in which unsynchronized component insertions can alter the interoperability properties of the overall system. Field testing involves functional testing and follow-on testing:
- Functional testing, the initial test in the field, cannot occur until people in the field have been trained in both the system and the business processes that the system will support. Functional testing involves configuring systems to meet the unique demands of particular customers, integrating products with the embedded base of systems (including earlier generations of the same product), and evaluating the resulting system of systems from the end-to-end functional perspective of the user.
- Follow-on testing assesses a system's performance after it has been fielded, reverifying interoperability periodically or as changes occur and providing a mechanism for tracking progress in addressing known problems. Some requirements cannot be adequately tested during the functional testing phase, and are best assessed during ongoing operations. Follow-on testing draws on information from multiple sources, including problem reports and lessons learned in joint operations and exercises, vendor information about features and bugs in new releases, and periodic monitoring of system performance and failures during field use.
In an ideal world, with an absolutely complete set of interface requirements and complete exercise of each system, conformance testing would catch all possible flaws. However, requirements are seldom complete enough to allow thorough testing, and complete testing takes too long. Often, requirements are strong in specifying behavior under ideal (sunny-day) conditions and weak about what should happen when it rains—for example, what the response of a system to a failure somewhere should be. System-to-system and field testing compensate by testing actual systems under a variety of conditions that go beyond those typically stated in requirements.
Testing should also be seen as an integral part of requirements definition and system development. Particularly in functional and follow-on testing, the value comes as much from having a process for learning about new requirements and feeding those requirements back from the operators to the developers as from identifying and correcting mistakes. As
spiral development (see the discussion of evolutionary acquisition in section 4.3.2) becomes the normal mode for acquiring C4I systems, such mechanisms for rapid feedback become especially important.
Thus testing must be essentially continuous, and "stability" is a state that is never reached in any meaningful sense. Only when information is fed back to system developers and maintainers can processes and systems be modified to help ensure continuing high performance as the operating environment changes. Without ongoing feedback, initial implementations of processes and systems may interoperate satisfactorily at first, but not later.
2.5 DOD Interoperability Strategy
Historical approaches to interoperability by the DOD have ranged from dealing with interoperability issues program by program to making limited-scope efforts on a joint, community-wide basis (e.g., the Joint Interoperability of Tactical Command and Control Systems activity to address joint message standards) or a functional community basis (e.g., air defense). In addition, some programs to develop defense-wide infrastructure, dating back to at least the 1960s, have been followed more recently by a few sizable, centrally managed application development programs (e.g., the Global Command and Control System as a replacement for the Worldwide Military Command and Control System).
In recognition of the leverage afforded by C4I and the importance of interoperability in realizing this leverage, over the last 3 or 4 years a more centralized, inherently joint/defense-wide strategy for promoting interoperability has emerged, comprising two major elements: a triad of interrelated architectures and a common defense-wide infrastructure, the Defense Information Infrastructure (DII) with a common applications platform, the Common Operating Environment (DII-COE, discussed in more detail below) as a key ingredient.18 Responsibility for interoperability is distributed across DOD, and each of the major players has at least one entity charged with responsibility for interoperability issues. For example, the Defense Information Systems Agency has the Joint Interoperability Test Command, the U.S. Atlantic Command has the Joint Battle Center, the Joint Staff has the Military Communications and Electronics Board, and the Assistant Secretary of Defense for C3I has the Information, Integration, and Interoperability Directorate. Today, DOD is just at the begin-
ning of refining and even establishing the processes and organizations to respond to future needs for C4I interoperability.
2.5.2 Elements of the DOD Strategy
The Defense Department has defined three interrelated architectures for C4I systems: the Joint Operational Architecture, the Joint Systems Architecture, and the Joint Technical Architecture (Box 2.9). The Joint Operational Architecture is intended to identify mission objectives, information exchange requirements, and logical connectivities among and within command and control units or organizations. The Joint System
BOX 2.9 The DOD Three-Part Architectural Framework
OPERATIONAL ARCHITECTURE—"a description (often graphical) of the operational elements, assigned tasks, and information flows required to support the warfighter. It defines the type of information [exchanged], the frequency of the exchange, and what tasks are supported by these information exchanges." The operational architecture is thus the doctrine-driven representation of C4ISR nodes, roles, processes, interrelationships, and data/information exchanges. This representation relates to specific scenarios and joint/combined/coalition mission functions and forms the basis for realistic process and information flow representation and prioritization.
SYSTEMS ARCHITECTURE—"a description, including graphics, of the systems and interconnections providing for or supporting a warfighting function. The systems architecture [view] defines the physical connection, location, and identification of the key nodes, circuits, networks, warfighting platforms, etc. associated with information exchange and specifies system performance parameters. The systems architecture [view] is constructed to satisfy operational architecture component requirements per the standards defined in the technical architecture."
TECHNICAL ARCHITECTURE—"a minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements whose purpose is to ensure that a conformant system satisfies a specific set of requirements. It identifies system services, interfaces, standards, and their relationships. It provides the framework upon which engineering specifications can be derived, guiding the implementation of systems."
SOURCE: C4ISR Integration Task Force. 1997. C4ISR Integration Task Force Executive Report, Department of Defense, Washington, D.C., November 30, p. 27.
Architecture is intended to map these information exchange requirements to specific hardware and software systems and to specify capacity and performance constraints. The Joint Technical Architecture identifies and mandates standards and identifies standards-compliant products, when available, for the building of systems and subsystems so as to promote interoperability between them.
The architectures are not all at the same level of development; the Joint Technical Architecture (JTA) is by far the most mature of the three. Wherever possible, the JTA references commercial standards, products, and technologies. The JTA is intended to provide a set of correct and mutually consistent technical standards, application interfaces (APIs), and protocols, along with decision rules for using them. The scope of the JTA is broad, encompassing systems for C4I, sustainment, weapons and platforms, and modeling and simulation. By conforming to the standards, products, and implementing guidance codified in the JTA, such systems are intended to be "born joint," in accordance with Chairman of the Joint Chiefs of Staff Instruction 6212.01A.19
The Joint Technical Architecture also provides an important foundation for coping with unforeseen requirements. The investment in the basic level of interoperability that is offered by building systems in compliance with the Joint Technical Architecture establishes a defense-wide fundamental level of interoperability, which permits a much more rapid accommodation to new scenarios and operational requirements than would be possible without it.
As far as the committee has been able to determine, the Joint Operational Architecture was originally intended to be a construct covering all military operations. For example, the 1998 Annual Report of the Secretary of Defense states that "the DOD is developing an agency-wide Joint Operational Architecture that describes the tasks and activities, operational elements, and information flows required to accomplish or support the missions of the DOD."20 The Information Superiority Campaign Plan of the Joint Chiefs of Staff calls for "the development of a high-level, C4 Joint Operational Architecture that integrates the joint warfare functions, from national level through operational level, into implementations of the JV2010 [Joint Vision 2010] operational concepts."21
Chairman of the Joint Chiefs of Staff. 1995. Instruction 6212.01A: Compatibility, Interoperability, and Integration of Command, Control, Communications, Computers, and Intelligence Systems, Joint Chiefs of Staff, Washington, D.C., June.
William S. Cohen. 1998. Annual Report to the President and to Congress, Department offense, Washington, D.C. Appendix K is available online at <http://www.dtic.mil/execsec/adr98/apdx_k.html>.
Information Superiority Campaign Plan, J-6, Joint Chiefs of Staff, Washington, D.C., available online at <http://www.dtic.mil/jcs/j6/campaign/task3_l.html>.
DOD architectural development to date, which has focused on the Joint Technical Architecture—conformance to a "building code" and standards—is, as DOD recognizes, in and of itself insufficient to ensure technical C4I interoperability, since it fails to address some of the most important architectural elements required for interoperability. Many critical architectural elements, not yet developed, would be contained within the yet-to-be developed Joint Systems and Joint Operational architectures. Used in combination, these would define interoperability requirements to support operational mission information flows. For example, the Operational Architecture and Systems Architecture for a particular operational activity would define which service-developed systems would have to exchange what information over what media in what format.
The committee recognizes that development of the Joint Technical Architecture was a pragmatic first step to take, given that establishment of technical standards is much easier than establishment of an operational or systems architecture. The definition of information flows and data semantics required for operational or systems architectures is inherently complex, and additionally, provokes debate about how operations are to be conducted.
Common Information Infrastructure
A core element of the DOD strategy for C4I interoperability is the building of a common, defense-wide information infrastructure that includes but goes beyond traditional long-haul communications and associated services such as messaging. Box 1.3 in Chapter 1 describes a number of elements of the Defense Information Infrastructure (DII). The DII includes a set of common software, the DII-Common Operating Environment (COE), including increasingly capable middleware, on top of which service/mission-specific applications can be built. Software reuse/commonality is a key ingredient that is intended to reduce development time and cost as well as enhance interoperability. The DII, with the COE as a key element, is envisioned as a DOD-wide "public utility" that can be extended into theaters of operations for support of wartime as well as peacetime use.22 Service- and mission-unique applications are to operate on a "plug and play" basis (e.g., software application program interfaces), with the common infrastructure providing basic capabilities and services. Use of the DII-COE and achieving compliance at certain levels is specified in the Joint Technical Architecture.
Note, however, that this homogeneous common infrastructure constitutes a potential information security vulnerability. See section 3.2.5.
Applications-level interoperability depends in part on the capability for exchange of data among applications in a way that both preserves meaning and is mutually interpretable. DOD understands the importance of data integration and has over the years launched two major efforts in this area:
- DOD Directive 8320.1, ''The Enterprise Data Model Initiative," sets forth a DOD process through which standard data definitions in functional areas (e.g., C4I, logistics, health care) are developed and then subjected to a cross-functional review process prior to being adopted as DOD standards.23 The goal of this process is to develop a complete set of standard data elements for DOD applications. The ultimate intent of the initiative is to bring all these data models together into one DOD-wide standard. One tangible result of this initiative is the DOD Command and Control Core Data model, which is now contained in the Defense Data Dictionary System managed by the Defense Information Systems Agency. Today, compliance with DOD Directive 8320.1 is mandated by the Joint Technical Architecture.
- In contrast to the "top-down approach" of DOD Directive 8320.1, the Shared Data Environment (SHADE) program relies on a "bottom-up" approach. SHADE is intended to enable different C4I systems to share data segments (portions of databases, including those associated with legacy systems) and to use standardized access methods.24 SHADE does not standardize data elements overtly. Instead, SHADE provides middleware for translating data elements from one system for another's use. If two systems have data elements with the same meaning (an assumption that must be tested in each case) and SHADE has a corresponding data element, then the middleware can transparently translate the data from one system though the common SHADE element and then back to the other system. SHADE presumes that, for reasons of cost and convenience, existing database segments will be reused and shared, and DOD data will increasingly reside in standardized, shared database segments. SHADE has demonstrated some success in enabling legacy systems to interoperate.
Department of Defense Directive 8230.1-M, "DOD Data Administration," September 26, 1991.
The Defense Information System Agency's Defense Information Infrastructure (DII) Shared Data Environment (SHADE) Capstone Document, July 11, 1996, is the basis for this discussion. This document and additional information regarding SHADE can be found online at <http://diides.ncr.disa.mil/shade>.
2.6 Measuring Interoperability
Evaluating current status or measuring progress in an area as complex as interoperability is difficult owing both to its multidimensionality (i.e., no single metric can possibly suffice to indicate the state of interoperability) and the difficulty in developing and applying precise metrics. Today, overall C4I status is generally introduced into readiness assessments as the judgment of a commander estimating his/her ability to accomplish his/her mission(s). An Army commander, for instance, generates a mission accomplishment estimate (MAE) with the status of C4I qualitatively considered along with the "measurements" of readiness for equipment, personnel, and training. The interoperability component of C4I readiness is particularly difficult to assess. For one thing, unlike other kinds of resources typically included in readiness reporting (e.g., personnel, equipment on board, equipment serviceability, training reported at the unit level), interoperability inherently cuts across units.
Although some qualitative assessments of the status of a unit's C4I systems, including interoperability, may enter into readiness assessments using today's process, the increasing importance of and reliance on C4I support of military operations suggest that the status and health of C4I—along with interoperability and other key aspects—be introduced as a more explicit and objective (rather than implied and subjective) factor. In the absence of precise metrics and recognizing multidimensionality, it is reasonable to use scorecard techniques based on human judgment to capture how well a unit (or DOD as a whole) is doing with respect to technical implementation compliance, system-to-system interactions, and operational mission effectiveness.
2.6.1 A Technical Compliance Scorecard
The technical view of an architecture focuses on the criteria governing the implementation of specific system capabilities or attributes. From an assessment perspective, the concern is whether a given system's implementations comply with the applicable standards and guidelines. A technical compliance scorecard could be viewed as a list of systems with pass/ marginal/fail ("green"/"yellow"/"red") ratings of their compliance with the relevant standards and guidance (Figure 2.1). 25
2.6.2 A Systems Interoperability Scorecard
The systems view of an architecture focuses on the information and communications systems that are brought to bear to support the information flows required to accomplish operational missions and attempts to measure the degree to which the various system pairs can effectively interoperate in context to meet these information flow requirements. These information flow requirements indicate the content and nature of the information and services needed, their directional flow, and the constraints and demands imposed by the operational environment. Accepting some oversimplification, one can view the problem as decomposition of a system architecture into a set of interconnected system pairs, which must each be able interoperate at some level of interoperability.
In this view, a scorecard used to measure interoperability from a systems perspective would derive from a codified (or de facto) system architecture, and would focus on the ability of the systems in each pair to interact with one another. Whereas in the technical compliance scorecard individual systems are assessed in isolation from each other, in the sys-
tems interoperability scorecard two systems can be scored as being interoperable with each other in terms of the kind and level of interoperability needed.26 The scorecard (Figure 2.2) could be viewed as a matrix with the systems represented in both the rows and columns and entries indicating system-to-system interoperability as inadequate ("red"), marginal ("yellow"), or adequate ("green").
2.6.3 An Operational (Mission-Enabling) Interoperability Scorecard
The operational view of an architecture addresses particular mission or operational slices, such as targeting, close air support, force sustainment, or the like, of a broader operational setting. Within each slice, it captures the players involved and their interactions, their functions, deci-
sions, and actions, and the flows of information postulated to support their particular roles in achieving overall mission effectiveness. Operational architecture perspectives can be depicted using node connectivity diagrams, where the node-to-node connections are described in terms of information flow requirements indicating the content and nature of the information and services needed, its directional flow, and the constraints and demands imposed by the operational environment.
A scorecard used to assess interoperability from an operational architecture perspective would focus on the ability to satisfy specific node-to-node information flow requirements (see Figure 2.3) and the collective set of flows needed to satisfy a defined mission or mission slice. The assessed degree to which each flow requirement can be met can be scored using green/yellow/red ratings. These metrics are often derived from lessons learned through crises or exercises (observed events and anecdotal feedback). They deal, of course, with questions of interoperability and not with the difficult, higher-level topic of measuring mission effectiveness.
Although much has been done to achieve C4I interoperability, the goal of a C4I system of systems with assured interoperability for the U.S. military continues to be unachieved. DOD faces major challenges to assure effective exploitation of C4I. Progress has in many cases been slow, and past C4I studies show that many documented C4I interoperability problems remain unresolved.27 Significant problems have occurred recently that have required significant time and resources to resolve (e.g., in the Gulf War; Bosnia).
The achievement of interoperability across a large-scale, complex C4I system of systems supporting military operations is a difficult undertaking. Despite increased attention and management awareness, along with a set of initiatives and strategies that the committee applauds, much more must be done before the infrastructure of C4I systems is as a whole largely interoperable and all new systems are sufficiently interoperable with the appropriate partners.
As discussed above, DOD has undertaken a number of efforts, at multiple levels within the services, the Joint Staff, the Office of the Secretary of Defense, and Defense-wide agencies, to deal with these challenges. Parts of DOD are well aware of a defense-wide problem in exploiting rapidly changing information technologies, in using COTS products effectively, and in assuring security. Today, a DOD strategy to promote interoperability exists, resting on the development and promulgation of technical standards such as the Joint Technical Architecture, the extensive use of middleware, and the evolution of a broader, enterprise-wide, common infrastructure.
Finding I-1: While the elements of DOD's current strategy for achieving interoperability are positive, they are not being fully executed. Both formulation and implementation have gaps and shortfalls.
Achieving interoperability in a changing world is hard. The DOD technical strategy (adopting an architectural approach, building to standards defined by the Joint Technical Architecture, and developing a common, defense-wide "public utility" infrastructure) builds on the best common practice in industry. It is a very important step that promises to significantly improve interoperability over time. At the same time, this
strategy is not being fully executed. The committee highlights three areas in which execution has been deficient.
Lack of Progress in Development and Implementation of the Joint Systems and Joint Operational Architectures
The Joint Technical Architecture and its DII-COE and SHADE adjuncts are useful efforts. But they can only enable and facilitate interoperability, rather than assure it. The Joint Technical Architecture is only one part of the triad of operational, systems, and technical architecture. Furthermore, the Joint Technical Architecture and DII-COE address interoperability problems at the "lower layers" (e.g., data transport), leaving a large universe of "higher-layer" data and applications interoperability topics (e.g., data semantics) still on the table, though being worked on.
DOD is not fully executing its strategy in the formulation of the Joint Systems Architecture and the Joint Operational Architecture. The committee fully supports the fundamental idea underlying the Joint Operational Architecture, namely that obtaining the maximum value from C4I systems and networks depends on an understanding of how information is used by various parties in various circumstances (i.e., different operational scenarios) and how that information must flow between parties to support military operations. At the same time, the committee believes that the universe of all possible military operations is simply too large for a single Joint Operational Architecture to be developed successfully, and thus prospects for progress through a single DOD-wide operational architecture effort comparable to that of the Joint Technical Architecture are doubtful.
The committee did encounter some service activities, such as those of the Army Force XXI architect, that are seriously dealing with these issues, but did not see any visible effort to extend them into the joint arena. Significant progress on the Joint Systems Architecture was not apparent. A major reason the strategy is not being executed is that the DOD has defined an approach that is too broad in scope. For this reason, it is not surprising that Joint Operational Architecture efforts to date have mostly been void of operational content, with progress largely limited to definition of a framework and formalism.
One consequence of the lack of progress on the operational and system architectures is that the DOD strategy is thus far largely silent on security, except for security standards contained within the Joint Technical Architecture. One instance of this is the lack of architectural guidance for reconfiguring systems in response to cyber-attack. A common (and reasonable) response to increased levels of cyber-threat (Chapter 3) is for a system to drop non-mission-critical functions ("reconfigure the system"
so as to reduce the number of avenues of information attack). However, in a visit to one exercise, the committee learned that mission-critical and non-mission-critical functions were not easily separated in the (implicit) Operational and Systems architectures of the operations center. Mission-critical functions were determined by a process in which all functionality is disabled and then individual functions restored (designated as mission-critical) when someone in the operations center demands them.
Security considerations cannot be managed in isolation. System architectures must deal with the issues of boundaries of trust and configuration controls relevant to that system. Operational architectures are intimately related to security because they specify information flows, and help identify those mission-critical functions for which information flows must be assured even under conditions of threat. Real-time determination of mission-critical functions while under attack is inevitably much more haphazard than a thoughtful consideration—included in the architectural design—of what functions are mission-critical at what level of threat.
Lack of Compliance with the Joint Technical Architecture
A major problem with the standards and common infrastructure approach has been a lack of compliance. For example, a recent DOD Inspector General report found that program plans for a large number of C4I projects did not call for conformance to the Joint Technical Architecture, even though those projects were subject to defense-wide guidance directing Joint Technical Architecture conformance.28 The committee observes that if some written plans say nothing about compliance, it can only be assumed that others that do promise compliance will not in fact deliver. The report concluded that DOD does not have an integrated or coordinated approach to implementing the Joint Technical Architecture, and thus has little assurance that the Joint Technical Architecture will meet DOD interoperability goals.
A report by the General Accounting Office concluded that DOD organizations are not complying with the current interoperability testing and certification process for existing, newly developed, and modified C4I systems.29 The General Accounting Office further found that in some cases, DOD program officials ignored the guidance, while in other cases, they were simply unaware of it.
These findings are consistent with the committee's sampling of C4I programs. Officials from the Office of the Assistant Secretary of Defense for C3I expressed to the committee their frustration at trying to persuade program managers to pay proper attention to C4I interoperability issues. Indeed, one person from that office argued that a major problem was that the definition of C4I technology and systems was porous enough that program managers could argue that they were not subject to directives applying to C4I systems.
Given that even with a formal process in place, Joint Technical Architecture compliance remains a major issue, the committee has concerns as to how system and operational architectures will be used. Indeed, it is unclear if an effective process is in place to use the system and operational architectures for development and fielding of systems.
The committee believes that the senior management of DOD recognizes many of the issues, such as the need for enforcement and providing sufficient resources for interoperability compliance efforts, but finds managing these issues to be extremely difficult. It is hard to enforce mandatory standards and guidelines across such a large organization. In addition, the term "mandatory" immediately raises the argument that there is legitimate mission-driven uniqueness, an argument that can only be addressed case by case. There is also concern about "unfunded mandates" except in cases where no additional cost is incurred, a rare situation.
The committee recognizes the limitations of an approach to interoperability that is based on enforcement. Effective enforcement of directives depends on enforcing bodies that have the authority to stop projects, resources to inspect the projects for which they are responsible, and willingness to exercise their authority.30 Under such an arrangement, only a few programs can be influenced, and many others can escape the oversight and enforcement process. Nevertheless, particularly in the short run, there seems to be no viable alternative to enforcement as a management strategy. In the long run, interoperability will flourish only if DOD is able to promote a culture in which interoperability is valued, and in which individuals have strong incentives to build interoperable systems where required to support joint and defense-wide operations. Fundamentally, program managers must feel that their programs have failed unless they are interoperable. The Institute for Military Information Technology proposed in Recommendation P-3 (see section 4.8) would be an important venue for fostering a culture that values interoperability more highly, and
would provide an environment supportive of the requisite cross-service collaboration.
Only Partial Success in Building and Using a Common Infrastructure
The DOD interoperability strategy rests in part on the use of a common infrastructure, the Defense Information Infrastructure (DII; see Box 1.3 in Chapter 1 for a description of some major common infrastructure programs), including a common software base, the Common Operating Environment (COE). In general, there has been insufficient migration toward the use of common infrastructure. Despite the commitment in policy toward use of a common infrastructure, there is still a proliferation of "stovepipe" systems.
Also, there is insufficient use of commercial products in the common infrastructure. Successful implementation of the DII-COE initiative requires attention to which functions should be DOD-developed and which should be taken from commercially available software. Also, the common infrastructure strategy requires careful attention to which operating system platforms the DII-COE will support. The common functions of DII-COE are implemented in a layer of software that is built upon an underlying operating system. The DII-COE must have a strategy for how it will manage multiple operating systems and evolve with the market for operating systems. The underlying operating systems should be COTS technology for a variety of reasons. These include the benefits of development investments based on a market much larger than DOD, testing by a larger community of users than DOD, maintenance costs that are borne by a larger base than DOD, functionality whose value is determined by the marketplace, and, most importantly, robust and creative COTS middleware and applications that are developed for high-volume platforms.
The committee observed that C4I systems today use a combination of UNIX and Windows operating systems. These represent the current choices for COTS operating systems. The DOD, like private industry, must monitor the market for these products, influence its direction, and respond to changes in its direction. For example, at present Windows enjoys the dominant share of the desktop, and a substantial and potentially growing share of servers. This market share, combined with other forces, attracts developers of middleware and applications that are of great potential value to DOD in C4I applications. A simple, but important, example that the committee observed in its field trips was the large number of office software suites for word processing and presentation graphics being used as part of the command and control process and providing important information flows.
The commercial sector, like DOD, must attempt to forecast and monitor industry efforts to replace the dominant product in the information technology marketplace, and adjust its COTS strategy accordingly. Examples of such attacks in the marketplace for application platforms include the Network Computer and Java, and Linux. The committee has no special insight into how dominant products in the market for operating systems may change. The committee does recognize that as changes occur, DOD must be committed to adapting the concepts of DII-COE to use the dominant operating systems to fully take advantage of COTS software.
In addition to having an operating system strategy for underpinning the DII-COE, DOD must continue to base middleware functions of the DII-COE increasingly on commercial products. For example, the committee sees Common Object Request Broker Architecture (CORBA) and Component Object Model (COM) as potential COTS replacements for certain elements within the current DII-COE. As with operating systems, DOD needs to monitor, forecast, and adapt to the market for middleware. The decision to adopt COTS components, an objective the committee endorses, should be based on an assessment of the trade-offs between the degree of support of specific DOD needs and the leverage afforded by using COTS. The committee sees this analysis as framed by determining when COTS does ''80%" of what is required, and the impacts of adapting applications that use the DII-COE to a new middleware environment. The "80%" rule recognizes the benefits of replacing DOD development and support costs with purchase costs based on high-volume components, wider and more extensive testing, and benefits similar to those of the COTS operating system market (see above).
Finding I-2: Even full execution of the DOD strategy for interoperability will not assure that joint mission needs for C4I will be met.
Present efforts in the DOD interoperability strategy suffer from a number of weaknesses:
- More must be done to prioritize interoperability needs and make the problem more manageable. DOD efforts to construct a single Joint Operational Architecture are tantamount to specifying the information needs and requirements for all operations that the DOD believes it will have to conduct in the future. It would also have to cover an evolving set of C4I components and systems. Understanding the possible information exchanges between systems and components is at least an N(N - 1)/2 problem (i.e., the number of possible pairs among N components). Because a single Joint Operating Architecture would require understanding how
- every part of a C4I system could be used in combination with every other part of any C4I system or component that is fielded, the unavoidable conclusion is that the ability to understand the entire system of systems does not scale well as components are added, and is clearly impractical.
On the other hand, an approach that depends on achieving interoperability on a pairwise basis is too narrow in scope. Because C4I systems are likely to grow in number and be synergistic and cooperative in their applications, a pairwise approach is unlikely to keep up with interoperability demands. These considerations suggest that the proper scope of a domain in which to address architectural issues is one that is more limited than "all military operations" but larger in scope than a pairwise system-to-system interaction.
The committee believes that a good organizing principle is that "proper" would be defined as a scope of analysis and concern that has operational significance, that is inherently joint, and that involves multiple systems. The same arguments apply to data standardization efforts and to the selection and use of tools that enhance data interoperability.
- There is insufficient attention to building in interoperability throughout the life cycle of C4I systems. Achievement of interoperability requires attention throughout development, testing, fielding, and deployment. The committee believes that current acquisition processes do not place sufficient emphasis on incorporation of interoperability during development. Once systems are fielded, a special emphasis is required on continued testing and verification of interoperability between systems. Even with such a regime of testing, interoperability problems will arise when units are actually fielded and systems are interconnected to meet the operational requirements of particular missions. Field support for commanders requires personnel who are knowledgeable and experienced in resolving interoperability problems, and who have a perspective that cuts across the full spectrum of C4I systems that interoperate.
- There is no system in place to measure the interoperability state of C4I systems. As discussed in Chapter 4, it is generally accepted that management must be able to measure what they wish to change. Today DOD management does not have in place measures of the current state of interoperability, either for assessing progress in developing and acquiring interoperable systems or for assessing the interoperability component of force readiness.
- The strategy does not provide concrete guidance regarding technology evolution and the role of COTS technology. Because the life cycle of C4I systems is long compared to the rate at which commercial information technology evolves, deployment is not an event occurring in a point in time but rather a process that takes place over years. Thus, architectures should provide guidance regarding strategies for deployment of the various com-
- ponents, both hardware and software, how they may be upgraded as the underlying information technologies increase in power and functionality, and most importantly, how upgraded systems will maintain interoperability with systems based on earlier generations of components.
- Data interoperability efforts are inadequate. Data interoperability standards referenced in the Joint Technical Architecture, such as the Defense Data Dictionary System, are mandatory defense-wide. But commercial experience suggests that because successful data models are based on an understanding of the interfaces in a system and how those interfaces are to be used, data models are more properly tied to operational and system architectures. Without them, an attempt at a data model will fail. Furthermore, an attempt at a DOD-wide data model seems doomed to failure as well—too many competing interests need to be coordinated, and it is likely that the effort will never converge.
The approach taken by SHADE is essentially the "data bus" approach described above. Such tools are potentially useful but require systematic application to operational mission areas for this potential to be realized. The committee's concerns are with regard to management and process rather than the technical approach. The SHADE effort depends on what amounts to voluntary adherence to a data interoperability regime. The committee understands the rationale for a voluntary regime, but remains concerned that persuading C4I program managers to use the SHADE approach will simply take too long to achieve a significant degree of data interoperability.
This chapter lays out a set of challenges that DOD faces in attempting to achieve a sufficient level of C4I system interoperability. The committee notes that some of these challenges stem at least in part from a broader issue, namely, the distributed, horizontal structure and organization of DOD itself, as established by Title X. In the recommendations that follow, the committee assumes no changes to this fundamental framework.
The committee's approach in making recommendations is to base them on principles and lessons learned from both the military and commercial sectors, and to focus more on outcomes than specific means. Thus the recommendations do not provide a high level of detail in identifying the specific ways to achieve these outcomes; these decisions will be dynamic in nature and are rightly made by the actors specified in the recommendations below.
Finally, the committee notes that its recommendations have applicability to the challenge of interoperability with at least a subset of coalition
partners. Interoperability with partners that are unanticipated, and with whom no strong cooperative framework is in place, can largely be approached only through adherence to and influence on worldwide commercial standards. However, interoperability with partners who are members of an existing alliance framework or mechanism such as NATO or the U.S. military relationship with Korea, can be addressed by using approaches similar to those recommended below for dealing with joint interoperability: (a) the use of mission slices to focus architectural efforts, (b) the use of standards, particularly commercial ones, (c) a bias toward the use of COTS technology, (d) the scorecard approach to measuring progress in achieving interoperability, and (e) the establishment of a testing and field support activity. The committee recognizes, however, that the level of management complexity is clearly much greater when multiple nations are concerned.
Recommendation I-1: The Assistant Secretary of Defense for C3I and the Joint Chiefs of Staff should complement the DOD's current broad interoperability strategy with focused efforts in limited, operationally important domains, to include the development of Joint Operational and Joint Systems architectures for these domains.
The committee believes that it is more feasible to develop operational architectures developed for particular joint missions or tasks, organized around either significant operational capabilities or mission slices. When the spectrum of military operations is decomposed into joint "mission slices" and their supporting information "threads," the scope of the architecture problem and the data standardization problem both become more manageable. A mission slice is a component of an overall theater mission, such as close air support, suppression of enemy air defenses, or theater air and missile defense. Information ''threads" supporting mission slices (e.g., the track files needed to support a theater air defense mission slice or the information flows associated with generation and execution of an air tasking order) can be identified and analyzed. These slices should not be confused with the sorts of vertical applications that were solved by what are today viewed as stovepipe solutions. Rather, they are intended as horizontal slices across the services and specific C4I systems.
A focus on architecture development for mission slices and information threads has two major advantages. The first is that is it allows DOD to set priorities. Progress in interoperability will take years, and the interoperability problem will never be solved "for good." It therefore makes sense to focus efforts on the areas of highest importance to the DOD. The second is that by prioritizing its efforts, processes and tools and techniques developed for the first efforts can be applied to later ef-
forts, making those efforts easier to manage and more likely to be successful. This recommendation is not motivated simply by recognition of resource limitations or the need to "learn by doing." It also reflects the committee's view that an all-at-once development of an operational architecture covering the entire span of DOD's operational requirements is infeasible.
Criteria recommended for selecting and defining a mission slice or operating capability as a focus for interoperability efforts include the following:
- The mission slice or operating capability should have considerable operational significance.
- The mission slice or operating capability should be inherently joint and involve a large enough number of systems to warrant the effort. Selecting such a slice or capability ensures that the architecture effort will be horizontal in nature, and thus resolve interoperability issues rather than create new stovepipes. For example, both theater air and missile defense and the single integrated air picture are inherently joint, as they involve a varied mix of sensors and weapons whose information flow requirements pass through multiple service boundaries.
- The mission slice or operating capability should have metrics or end-to-end performance indicators that can indicate improvement. For example, performance indicators for the effectiveness of air and missile defense have existed for a long time (e.g., percentage of attackers that penetrate the defenses). In systems that provide capabilities such as the single integrated air picture (SIAP), the number of reported air tracks in the systems for every real object in the air or other such data would serve as comparable quantitative indicators of performance.
- The mission slice should be one in which significant foundational work has been undertaken. One mission slice for which this is true is theater air/ missile defense, an area that is highly significant operationally, is associated with serious force integration issues, and—not least—has substantial operational and system architecture work already done by the Joint Theater Air Missile Defense Organization (operational architectures) and the Ballistic Missile Defense Organization (systems architectures).
Significant operational capabilities are another useful focus for interoperability efforts. The committee believes that programs providing a common operating picture represent a set of good choices, because they have broad applicability (interoperability needs are rich), are contained (bounded), and support an operational capability. Work on perhaps 10% to 20% of the data elements would yield a major interoperability payoff, and thus the effort, albeit expensive, would be rewarded. A key informa-
tion thread of the common operational picture (COP) is the data elements in the "track file"; this would be an appropriate first thread on which to focus attention. COP programs have been conceptualized to provide capabilities at several levels. For example, within the Global Command and Control System (GCCS), the COP provides a common operating picture at the headquarters level. Other examples of operational capabilities on which to focus include the common tactical picture (CTP) and the SIAP—both capabilities critical to achieving effective joint operations and status reporting up the chain of command.
It is understood that the lead for developing C4I architectures is a shared responsibility of the Directorate for C4I Systems of the Joint Staff (operational architecture) and Assistant Secretary of Defense for C3I (systems and technical architectures), with support coming from other DOD elements depending on which mission slice is selected (e.g., from the Joint Theater Air Missile Defense Organization if theater missile defense were chosen as the mission slice). Given the urgent need to develop an operational and system architecture to guide ongoing development, the committee recommends that the Directorate for C4 Systems of the Joint Staff and the Assistant Secretary of Defense for C3I select an appropriate mission slice and initiate an activity to develop operational and systems architectures as a mechanism for identifying and prioritizing interoperability needs and problems—both today and prospectively.
Again, the consideration of available foundational work is important and suggests that a candidate would be a collaborative Joint Theater Air Missile Defense Organization/Ballistic Missile Defense Organization effort on the theater missile defense mission—an activity that would yield specific results for a crucial joint mission and also serve as a pilot of the "mission slice" approach.31 Also, the committee believes that it would be useful to draw on service efforts to establish architectures for guidance in selecting mission slices and management approaches.
Note that it is not the intent of this recommendation to suggest that DOD should concentrate only on limited domains. The focused activities recommended here are intended to complement the standards and common infrastructure elements that provide a necessary foundation for mission-specific capabilities.32
Recommendation I-2: The Secretary of Defense should establish a joint C4I integration and interoperability activity to address integration and interoperability throughout the entire life cycle of C4I systems.
The committee believes that an appropriate augmentation of current DOD activities for promoting and facilitating C4I interoperability should focus on three areas: more cross-service testing that starts early in the development process, an increased emphasis on end-to-end field testing, and greater end-to-end interoperability support in operational contexts.
- Cross-service testing starting early in the development process . In particular, the testing component of current interoperability efforts is technically oriented and directed primarily at system-to-system testing when the development effort nears completion. Testing in general is oriented toward standards compliance or system acceptance rather than mission performance. The committee believes that to the extent possible, interoperability should be analyzed, assessed, and driven "top-down" by considerations of operational significance as well as facilitated "bottom-up" by the C4I technical community. Focusing on systems within a mission slice, such testing would augment current efforts by testing at application and data layers much earlier in the development process than current practice, perhaps even against paper requirements. Early attention to system-to-system testing for interoperability would make it easier to synchronize the objectives and time lines of different programs for C4I systems that must interoperate, reduce the effort needed to achieve interoperability, and decrease the time line required for addressing interoperability problems in the field by providing ''preventive medicine." In addition, it would avoid the cost and complexity entailed when problems are fixed late in the development process. Note that a cross-service development activity is consistent with the desire articulated by the Secretary of Defense in response to Section 912(c) of the Defense Authorization Act for FY 1998. Specifically, the Secretary of Defense expressed interest in ways to establish a joint command, control, and communication integrated system development process that focuses on developing a joint architecture to guide design and achieve integrated systems development.33
- Ongoing interoperability assurance in operational contexts. Notwithstanding "best efforts" to address interoperability problems before systems are fielded, unanticipated interoperability problems invariably arise as C4I systems are composed and configured in untested combinations in
See William S. Cohen. 1998. Secretary of Defense Report to Congress: Actions to Accelerate the Movement to the New Workforce Vision, Department of Defense, Washington, D.C.
- the field to support particular operational needs. Such problems are increasingly complex, demanding technical sophistication to address "higher-level" issues such as data interoperability. DOD does undertake some activities that address end-to-end C4I interoperability, but the committee is unaware of a process or mechanism in the DOD that systematically addresses C4I interoperability on an end-to-end basis, in a real-world operational setting, in a manner that provides assurance for commanders who will need to support critical operational jobs.
- Interoperability support for deployed forces. Deployable operational support for interoperability would help joint task force commanders to address and respond to interoperability problems and issues as they inevitably arise in the field. Deployed in much the same way that the Joint Communications Support Element deploys, "field interoperability support teams" would deploy as an initial cadre with a joint task force first to guide the interconnection of C4I systems in-theater and then to provide sustaining support as required, focusing on integrating and ensuring the interoperability all CINC/service-provided C4I systems (specifically including decision-making/decision-executing information systems as well as communications systems). Field integration/interoperability support teams would involve designated sets of broadly skilled information systems and networking personnel and tools to support their work. Using specialists who are intimately familiar with C4I systems being deployed would increase the likelihood that interoperability problems could be resolved under the extreme time pressures that characterize many operational deployments. Because they would be intimately familiar with the design and development foundations of fielded C4I systems, field integration support teams would have an important advantage over today's deployed "signal" units with respect to certain classes of problems. In addition, they would have the technical background to be able to speak knowledgeably to system suppliers and vendors to obtain high levels of technical support to fix interoperability problems in the field (e.g., by obtaining software patches).34
The committee also notes that force interoperability would be more easily achieved, and the burden of field integration reduced, if planning for contingencies were less ad hoc. Deliberate operational planning—
perhaps in conjunction with predesignation of joint task force commanders—by the force provider would permit much better advance knowledge of which forces would be called upon to interact in a given contingency. With such knowledge, the force provider would be in a better position to focus testing, training, and the like, so as to maximize the interoperability of forces that would be called upon to carry out a particular deployment.
Development, field testing, and operational support draw on the same knowledge and experience base and are inherently synergistic—testing builds expertise that is valuable for field support, and field activities improve future design, development, and test efforts. Also, as an organization that includes both developers and testers, and that has direct contact with end users in the field, a joint C4I integration and interoperability activity would provide a collaborative environment that would foster less adversarial relationships more akin to those increasingly evident in the commercial sector (see section 2.4 and Box 2.8).
To build and sustain the expertise that field integration/interoperability teams need in order to be able to address interoperability problems "on the fly," the joint C4I integration and interoperability activity would have a peacetime role that includes:
- Interaction with users. The joint C4I integration and interoperability activity would interact with users in the conduct of acceptance tests as well as the subsequent readiness tests that are used by forces in deciding whether to field an accepted system. During its site visits, the committee observed several instances of such collaboration. 35
- Conducting cross-service/agency interoperability tests. This work would include identifying and synchronizing test opportunities as programs progress through their individual development cycles (within the spiral model framework).
- Participation in joint and service-sponsored tests and exercises.
- Education and training of personnel on interoperability issues. For example, the joint C4I integration and interoperability activity would train field operational personnel to prevent the decreased interoperability that can result from applying ad hoc solutions to field problems.
- C4I configuration and version management. The joint C4I integration and interoperability activity would develop rules and guidelines to identify configurations of C4I systems—including software and hardware versions—that are known to interoperate with others and provide codified guidance to operational commanders as to what units and C4I systems would interoperate in a deployment.
- Development of fixes and work-arounds to resolve interoperability problems. Dealing with interoperability topics at the "higher level" demands being conversant with variations among successive software and hardware releases associated with a particular product line or functionality. This knowledge would also be transferred to operational commands in the form of advice as to what units and systems could and could not be made to interoperate in a deployment.
Doing the work described above would keep personnel familiar with the "building blocks" that could be delivered to the field and from which an end-to-end joint capability would be configured.
During exercises and operational deployments, the joint C4I integration and interoperability activity would offer advice to commanders in planning deployments and provide field support to fix interoperability problems. The technical expertise regarding C4I systems, together with the operational perspective gained from its involvement with joint exercises and deployments, makes the joint C4I integration and interoperability activity a powerful mechanism for improving the coupling between the development community and the community of users.
Where Should the Joint C4I Integration and Interoperability Activity Be Established?
The committee believes that specifying function is more important than specifying organization. Nonetheless, it notes that several organizations—both existing and proposed—have missions that overlap with the proposed joint C4I integration and interoperability activity:
- The Joint Interoperability Test Center in Fort Huachuca, Arizona, plays an important role in technical interoperability testing. Also, while the Joint Interoperability Test Center does not have a formal role for testing interoperability across systems from different services at a functional or operational level (nor does any other DOD agency or organization), its personnel in fact do provide a measure of operational support to exercises. In fact, briefings from the Joint Interoperability Test Center suggested to the committee that this organization is placing increasing emphasis on field support.
- Cross-service development activities are undertaken by the major service C4I developers (the Air Force Electronic Systems Command, the Army Communications and Electronics Command, and the Navy Space and Naval Warfare Systems Command), the associated program executive officers and program managers, the Defense Information Systems Agency, and end users. Existing and emerging service developer capabilities include the Electronic Systems Command's Command and Control Unified Battlespace Environment, the Communication and Electronics Command's Digital Integration Laboratory, and the Space and Naval Warfare Systems Command's Integration Laboratory and Advanced Concepts site, as well as other efforts to establish a joint developer's test bed. Including service developers in an activity that provides field support would add a measure of detailed expertise that is often needed to resolve interoperability problems in the field.
- The proposed interconnection of service/agency development facilities resembles the concept of the battle laboratory "federation" associated with the recently formed Joint Battle Center but is intended to emphasize developmental phase, working level, technically based testing prior to and after formal evaluations.
- The Under Secretary of Defense for Acquisition and Technology and the Assistant Secretary of Defense for C3I were tasked by the Secretary of Defense to examine ways to achieve objectives that are, in part, similar to the proposed joint C4I integration and interoperability activity.36 The tasking specifically requested submission of an implementation plan to streamline the acquisition organizations, work force, and infrastructure. Despite the general focus on streamlining and infrastructure redirection, the section of the Secretary's report devoted to the restructuring of research, development, testing, and evaluation identified C4I shortfalls vis-à-vis the conduct of joint operations and directed that a study group be formed to address responsive improvements.37
A study group composed of the commanders of the three primary service C4I acquisition commands (the Air Force Electronic Systems Command, the Army Communications and Electronics Command, and the Navy Space and Naval Warfare Systems Command) was established and, under the guidance of the Under Secretary of Defense for Acquisition and Technology and the Assistant Secretary of Defense for C3I, has evolved a concept for improving C4I integration and interoperability. As of this writing, the fundamental concept involves both (1) working across the acquisition/development commands and related organizations to ensure that systems are "built and tested joint" and (2) establishing tri-service acquisition/development command activities to respond to the needs and problems of the CINCs. An acquisition/development command management forum, the Joint C2 Integration and Interoperability Group, which reports to the Assistant Secretary of Defense for C3I and has mechanisms in place to incorporate the perspectives of other stakeholders, has been established.
The committee understands that a study report and implementation plan have been submitted to the Undersecretary of Defense for Acquisition and Technology. Although the specifics are still evolving, the committee applauds this initiative and views it as potentially addressing the intent of the cross-service development component of the committee's recommendation. As of this writing it is less clear if that would satisfy the on-call, high-level field support component also included in the committee's recommendation.
Recommendation I-3: The Secretary of Defense, the Assistant Secretary of Defense for C3I, and the Chairman of the Joint Chiefs of Staff should establish processes to assess C4I interoperability on a regular basis.
Interoperability is typically assessed by DOD through non-comprehensive perspectives that are focused, for example, on standards, COE compliance, data models, or certification criteria and how individual systems match up to such criteria or standards.
Although a definitive, rigorous analytical approach at a detailed level could be sought, what is key is an approach that provides an overview for management attention at upper levels of both the user (e.g., Joint Chiefs of Staff and the CINCs) and the developer (e.g., the Assistant Secretary of Defense for C3I and the services) communities. In this approach, the interoperability management challenge becomes one of addressing the state of interoperability throughout the enterprise, rather than attempting to strictly measure every variable in detail in each possible scenario.
Recommendation I-3.1: The Assistant Secretary of Defense for C3I and the Joint Chiefs of Staff should develop a set of "interoperability scorecards" as a basis for management, covering the spectrum from compliance with standards to successful end-to-end mission support.
A scorecard approach, which would be useful in assessing the status of cross-service C4I interoperability, is recommended. This approach would support problem prioritization, diagnosis, and correction, as well as operationally based assessment of the state of C4I interoperability for the use of system managers (e.g., the Office of the Assistant Secretary of Defense for C3I and the Military Communications and Electronics Board) and operational users (e.g., CINCs or joint task force commanders). The scorecard approach cannot provide sophistication and quantitative theoretically grounded measures. Rather, the fundamental motivator is to move to a point that interoperability is analyzed, assessed, and driven top-down by considerations of operational significance.
The approach uses three scorecards—technical, systems, and operational—corresponding to the elements of the architectural triad. The technical compliance scorecard would be used to assess a system's implementation from a technical interoperability perspective. It would take the form of a system profile or list for scoring each system implementation with respect to compliance or non-compliance with relevant standards and guidance. The systems interoperability scorecard would measure system to-system interoperability and would take the form of a matrix displaying the ability of all pairs of systems to interact with each other. The operational interoperability scorecard would be used to assess the ability of a set of systems to satisfy specific node-to-node information flow requirements as well as the collective set of information flows needed to satisfy a defined mission or mission slice.
Assessment requires that responsibility is assigned for (a) the development and definition of criteria, (b) actual conduct of the assessment, as well as (c) responsibility for ensuring that the results of the assessments translate into actions to remedy issues uncovered in the assessment. Responsibility should be assigned as follows:
- Development and definition of criteria. For assessment of technical and systems interoperability the committee believes that the Assistant Secretary of Defense for C3I should have the lead in development of criteria, and definition of operational interoperability criteria should be a joint responsibility of the Joint Chiefs of Staff and the combat commands.
- Conduct of interoperability assessments. Given the Defense Information Systems Agency's Joint Interoperability Test Center's role in testing compliance with the Joint Technical Architecture, it is appropriate
- that these organizations conduct the technical interoperability assessment. System developers and the organization proposed in Recommendation I-2 above are the logical responsible organizations to assess system interoperability. The operational interoperability assessments should be conducted by an appropriate organization as tasked by the Joint Chiefs of Staff (e.g., the Joint Theater Air Missile Defense Organization for theater missile defense). The responsible organizations should ensure that users play a key role in making such assessments. Without a process for continual assessment for interoperability, the user will have little sense for what interoperability problems need fixing and what their impact might be.
- Accountability for the results of the assessments. Accountability and responsibility for remedying shortcomings uncovered should lie with the Assistant Secretary of Defense for C3I in the case of the technical and system assessments and with the Joint Chiefs of Staff and the operational commands in the case of operational interoperability assessments.
Recommendation I-3.2: The Chairman of the Joint Chiefs of Staff should establish a process to incorporate C4I interoperability into readiness reporting.
Achieving and maintaining an adequate level of interoperability pose significant challenges. Indeed, given the large number of C4I systems that are increasingly expected to interoperate and given the increasing rate at which new hardware and software versions are being fielded, especially as the spiral development model is adopted, the state of interoperability in fielded systems requires ongoing attention.
To help in assessing progress toward meeting these challenges, C4I interoperability should be built into readiness reporting. It must, however, be done in a way that recognizes the characteristics of current combat readiness reporting, which emanates from the combat unit (i.e., a battalion, squadron, or ship) and reports on the status of things controlled directly by the unit or supported directly by its parent command (e.g., training, manning, availability of spare parts, in-commission rates for combat equipment).
The level at which C4I interoperability readiness can be measured and reported differs from the level of the factors included in current combat readiness reporting. Individual combat units are not necessarily in a position to ascertain the status of C4I systems external to their own units—the key issue in determining the ability to conduct joint combat operations. It is at echelons of command above combat units, particularly those with a joint perspective, where there is today no formal combat readiness reporting system, that the readiness of C4I systems can best be assessed.
Also, C4I is a more indirect contributor to combat power than factors that can be directly tied to a particular units' combat readiness.
The system that the Joint Chiefs of Staff develops must focus on assessing the readiness of forces to conduct end-to-end missions. The readiness reporting must be based on a realistic set of scenarios for how units are to be employed. It may be appropriate to focus assessment efforts in the same mission slices as those in which the activities proposed in Recommendation I-1 are conducted.
The joint force provider, the U.S. Atlantic Command, is in a unique position to provide cross-service visibility of the contribution of interoperability factors to readiness. Its ability to do so would be enhanced if it were to preplan which forces would be expected to be deployed in a given contingency, an approach that would also enable better assessment of interoperability as an element of readiness for that contingency.
Recommendation I-4: The services and agencies should designate an activity within the program offices for C4I systems (and weapons systems with embedded C4I) to be explicitly responsible for resolution of architectural and system-level issues that determine interoperability.
The committee believes that management attention to the interoperability of C4I systems is today often not an assured process. That is, while today's acquisition system does acknowledge the importance of C4I interoperability in its various directives, in actual practice the management attention afforded to C4I interoperability depends strongly on the temperament and inclinations of the individual program manager. Program managers who "buy into" the vision of interoperability pay a great deal of attention to that subject, while those who do not pay far less attention to it. The focus of this recommendation is not the development of additional acquisition policy but rather the filling of a gap in implementation and practice in program management.
The establishment of an "interoperability cell" or equivalent in C4I program offices would provide a central point of focus for interoperability issues. The fundamental principle of this activity is that for each C4I program there must be an activity charged with looking outward, cross-service, at interoperability issues. This cell would be responsible for revising or modifying architecture as needed to accommodate changes in doctrine, tactics, techniques, procedures, and equipment; engaging the stakeholders in a particular C4I system in the problem of defining and achieving interoperability for that system; and negotiating interoperability issues with those responsible for development/upgrade of "neighboring" systems. In its efforts, an interoperability cell could be expected to take a pragmatic approach that narrows the scope of the systems that must be
considered by the architectures (though not necessarily to those that are immediately adjacent to any given program), and limit the scope of the interoperability effort to particular configurations of components. In other words, interoperability cannot be realistically expected across an unlimited number of releases or versions. Such "bottom-up" negotiation of interoperability issues is intended to complement "top-down" architectural and common infrastructure efforts. The cell would also be responsible for elements that constitute an investment in future interoperability, such as metadata and appropriate interfaces.
The appropriate placement for an interoperability activity can vary. For a large program, placement within the program manager's office may be advantageous. In other cases, placement within a program executive office or service acquisition command may make sense—both for reasons of efficiency and to ensure that the "cell" has a sufficiently broad perspective. Somewhat similar functions have been performed by service elements such as the Air Force Electronic Systems Command, the Navy Space and Naval Warfare Systems Command, and the Army Communications and Electronics Command. However, there is no clear analogy to these organizations for joint systems.