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 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.