||C4I: Realizing the Potential of C4I
The needs of the operational military commander must be the main driver of interoperability solutions and investments. These needs exist both at the higher levels of
command (e.g., the specified unified commander-in-chief or the joint task
force commander) and at the tactical level where the services work together to
accomplish joint missions. Interoperability is valuable not for its own sake,
but only when it helps to accomplish a mission.
While universal interoperability is neither necessary nor achievable, a high degree of interoperability is needed to provide the flexibility required for both anticipated mission needs and unanticipated operational deployments. What
specific operations must be anticipated? Some are reasonably clear today
(e.g., U.S. war plans for responding to a North Korean attack in the Korean
peninsula define a specific operational context for U.S. and allied forces).
Even when the theater of operations is not known, certain mission needs are
likely (e.g., the need to ensure air superiority or to provide defenses
against ballistic and cruise missiles). But other contingencies in which U.S.
forces will be deployed will be unexpected, which places a premium on
flexibility in the operational capabilities of U.S. forces--including
Interoperability must be balanced against other fundamental attributes of C4I systems, including security, availability, flexibility, survivability, and performance.
Military commanders need many things from their C4I systems besides
interoperability, and trade-offs among these needs are often required.
C4I interoperability requires a unifying framework and a body of definitive implementing guidance. The C4I "system of systems" is large, complex, and distributed
across organizational, program, and geographical boundaries. A framework and
guidance are crucial because achieving C4I interoperability is largely a
matter of management, design, and implementation discipline rather than of
resolving technical issues. To date, the DOD has partially codified the
framework and guidance in the still-incomplete architectural triad of
technical, systems, and operational architectures.
When developing architectures, use a small team. Good architects are critical in
developing a good architecture. The role is demanding, requiring an ability to
balance needs and resources, technologies, and the interests of multiple
stakeholders. Good architectures usually result only when a small number of
people are responsible for their content and structure. Good architectures are
unlikely to emerge from a large team or from a broad consensus-based approach.
These almost always involve compromises that lead to excessive complexity
rather than a clear design philosophy, which in turn confuses the
Decompose the problem of achieving defense-wide interoperability into manageable pieces. This
principle arises from three underlying factors. First, the domain must be
sufficiently bounded that progress can be made before the key players, mission
requirements, or technology change significantly. An effort that is too large
will simply never reach closure. Second, the problem to be addressed must not
be overly complex. Third, the small teams required by the previous principle
can only undertake problems of limited scope. The defense-wide network of
systems, and the full spectrum of missions, are simply too large to be
approached in one single effort.
Assess interoperability on the basis of ongoing training and testing. Using standards makes
interoperability among C4I systems easier, but does not guarantee it.
Standards do not provide a complete design specification. Furthermore, given
the continuing, asynchronous fielding of new systems and capabilities,
interoperability is a time-perishable commodity. Only ongoing testing of a C4I
system throughout its life cycle will ensure interoperability. This must
include training and testing across a wide range of possible configurations
that includes the other C4I systems with which it is expected to
Measure progress toward interoperability goals. Measurement and assessment--and reporting of
results in a visible way--are essential to continued focus and to setting the
right priorities (an instance of the general measurement principle that is
articulated below under the process and culture goal). Despite laudable
case-by-case efforts, there is today no method for tracking interoperability
on a comprehensive or systematic basis.
Build a common defense-wide infrastructure to facilitate interoperability. Where common
systems and software are used, it is easier to make them interoperate. Common
infrastructure is not a cure-all, however. It will not, for example, address
some user or mission-specific needs.
Engineer for flexibility.
Use commercial off-the-shelf (COTS) products, services, and technology whenever possible. COTS products and services improve quickly, are more
sustainable, and are usually less expensive than those custom-provided to
the military. When commercial products are used, the vendor often assumes
much of the burden of ensuring interoperability and backward compatibility.
Decisions to use COTS products and services must, however, take into account
possible security risks.
Technical standards are one way of planning for the future. Compliance with
technical standards is an investment that makes future interoperability
easier, though by no means certain.0
Base architectures and system designs on layering and clean interfaces. Layered
architectures make it possible to exploit technological progress in some
parts of a system without the need for a total system redesign. Clean
interfaces make it easier to interoperate with other systems that conform to
those interfaces. Interfaces are an investment in the future: by providing
well-defined ways to access systems and capabilities, they make it easier to
compose these components in new ways in the future, or to use existing
systems in new ways.
Make data self-describing to permit future interoperability. Another investment in
future interoperability is to identify the meaning of data so that it can be
used in future applications. Examples include recording and transmitting not
only a position but also the coordinate system it is given in, or generating
a time stamp for a target track to help other systems resolve multiple
Finally, because the analysis of and solutions to
interoperability problems are inherently distributed throughout and across the
DOD, interoperability efforts should be guided by a final
Achieving interoperability requires responsibility and authority that crosses organizational boundaries--a requirement that implies the need for strong top-down leadership. This crossing of boundaries is particularly important
to the development and fielding of systems that support joint operations, as
well as to the development of doctrine for joint operations. The DOD must
search for practical ways to reward interoperability and impose sanctions for
ignoring it. Sanctions are unwieldy and can be applied only at great cost and
effort, and only in a few cases. Therefore, although they do have value in
focusing attention on flagrant offenders, it is much better in the long term
to establish a culture that rewards