Command systems are exemplified by military staff organizations that support a commander in the performance of a command mission. In the case of NORAD (North American Air Defense) the mission is primarily air defense of the North American Continent, with SAC (Strategic Air Command) the mission is strategic bombing; with the National Military Command System (NMCS) the mission is strategic direction of the U.S.
Armed Forces. Command systems contain elements of sensor systems, force reporting and management systems, and staff information processing and presentation systems. The ADP support in command systems can be of two types. In the first type, ADP is used in Class I applications by various staff elements. The size, cost, and complexity of the ADP sup-port depends upon the number of applications developed. In general, the many separate ADP applications are integrated by the staff, not by the ADP support. Thus, for the first type of support the discussion of Class I systems holds for the ADP aspects of the system.
In the second type an attempt is made to significantly automate many of the system functions. Thus, in addition to numerous Class I applica-tions, much of the resulting output is processed, integrated, evaluated against criteria provided by the staff, and displayed in summary form by machine. The second type of ADP support can presumably be arrived at in two ways, either late in the life of a Class I type of ADP-supported system, or by intentional design at the outset. To date only a few attempts have been made to implement command systems with ADP applications of the second type. The remainder of the discussion relates primarily to these attempts.
Total costs for command systems vary widely between systems, ranging from a few million to several hundred million dollars. For one small com-puter installed in existing space used as a data-storage and retrieval system supporting the staff, the cost is towards the low end of the scale. A system with a large command post, special protective construction, and extensive communications, may cost in excess of $100 million. A system with several alternate sites, internetted with communications and operational pro-cedures, may easily cost several hundred million dollars. In all cases, the
LARGE SYSTEMS 133 costs of the ADP complexes need not greatly exceed those of Class I systems.
In comparing the total costs of command systems with costs of other types of systems, caution should be exercised because significant cost elements are not normally counted. For example, the costs do not usually include associated sensor systems or the cost to the subordinate com-mands of acquiring the data required by the command system.
Startup times for command systems are long. An example of a system employing the first type of ADP support is that of USSTRICOM. At USSTRICOM, a computer was installed within a year, but two years were required to provide a data-retrieval capability to support a pre-dominately manual staff operation. Today, computations are being pro-grammed to relieve the staff of the more routine processing loads, and procurement is being initiated on the remaining elements of the system.
The NMCS has followed a pattern of development similar to that of USSTRICOM. For systems employing ADP of the second type, four to five years are required (as far as we know).
The degree of automation in command systems ranges from moderate to low. In systems where the mission has existed for some time and is subject to a certain measure of mathematical definition, both data-storage and retrieval functions and data-processing functions are performed.
In the case of newer commands or systems with large uncertainties (par-ticularly those at higher echelons), data-storage and retrieval functions are automated first, and only at some later time (perhaps) are the processing functions done by machine.
To date, reliance upon the ADP support to the command systems has usually been only moderate. For recent systems, the ADP support is ac-tually under development while installed in the user facility. To date in these cases development has not progressed to the point where ADP utilization records can be compared with those of other systems.
Performance from the standpoint of operational employment is accept-able for system applications with minimum functional uncertainty. When the functions are vaguely defined or where they vary, experience has been poor. From the standpoint of technology, application greatly lags the development of tools.
The complexity of the command system is as great or greater than that of the sensor-based system. Functionally the ADP complex usually sup-ports directly an operation center staff numbering twenty to thirty. In-directly the ADP complex often supports a much larger staff with more widely varying functions. On the other hand, the system usually does not receive data at the frequency of a sensor-based system.
The various negative factors of experience with command systems
make this the least attractive type of system to automate from a cost/
effectiveness view. The primary reasons for the negative results appear to be the uncertainty inherent in command environments, and the lack of ability for automated systems to quickly adapt to changing functions.
It would be ideal if system lead times could be made dependent upon equipment-acquisition schedules. To approach such a goal, system de-signers have recently been preoccupied with the problem of generalizing computer programming. Then instead of a system-design process forced to follow classical methods (Fig. 1), the "new design" method (Fig. 2)
FUNCTIONAL OESIGN
t----PERIOD OF OBSOLESCENCE - - - - . . t
TECHNICAL DESIGN
I MPLEMENTAT ION
T I M E
-CLASSICAL DESIGN APPROACH
Figure 1.
OPERATION
would permit more nearly parallel development of hardware and pro-gramming subsystems.
With the classical approach, a period of intense analysis was begun to define in ever-increasing detail the functional content of the system [functional design]. After the jobs were defined, sized, and analyzed for interrelations, the technical design was begun leading to equipment and program specification followed by periods of implementation and opera-tion. Duting this sequence, the user, heavily involved at first in job definition, becomes increasingly discontent. As time passes, more and more design compromises are built into the system, and in addition, his appreciation of his mission begins to deviate from his early projections.
As a result, by the time his system is operational, he can ill afford the addi-tionalloss of projected capability that occurs when trying to make a paper
...
1
specification function in the real world. Furthermore, to change his sys-tem.he must go back to the point in time early in the design cycle, gen-eralized programming techniques, important factors bearing upon equip-ment selection can be tackled early and equipequip-ment acquisition initiated.
Because the key to generalization is to construct the basic data-processing functions independent of the specification of operational function, pro-gram development can begin earlier, borrow more from other systems, and readily accommodate variations in operational function to be per-formed. As a result, user discontent is less pronounced. He may still have to suffer some loss of desired capability when faced by some hard technological facts. However, he is not additionally constrained by a need to seek premature definition of his functions, and he can reserve the right to change his mind within reason. He still faces disillusionment when he compares the product with the specification, but not to the same degree, and he can implement corrective changes in a much more reasonable time frame.
The recognition of the need for a new design approach began several years ago, and much progress has been made in this direction. While no one current operational system fully qualifies as an example, several have one or more important elements required for general purpose design.
The key issue in system design, however, is not tool design but applica-tion. Hand-in-hand with the recognized need to adopt a new design ap-proach for tools there is a need to address another major problem area where inadequate attention is usually paid, the area of data definition.
Before a system has operational value one must have tools to manipulate data, and data with sufficient information content. It is this last area that is most often neglected in command system development today. The neglect stems from two primary causes. First, the uncertainties inherent in system functions makes this area a most difficult one in which to work, often requiring tedious and costly analysis, definition, experimentation, modification and not infrequently a good deal of political negotiation before satisfactory solutions are hammered out. The second cause stems from the growing reliance upon the new design approach. Since the tech-nician can make the hardware and program development increasingly in-dependent of functional detail, he has begun to withdraw from this area.
He exerts less pressure upon the user to develop it, claiming rightfully that the area is the responsibility of the user, and he no longer employs a large amount of technical resource in the area.
To adequately plan for large systems it is necessary to understand the magnitude the problem data definition represents. It is not a major problem for a base commander to keep track of the status of his aircraft by type. However, if status must include data of significance to logistic support planners, and data to support force allocation planning, etc., the data records begin to get cumbersome. In the NMCS it is not uncommon for a file record to contain four or five subsets of data to support different functional aspects of file usage where each subset contains ten or more data fields.
To generate such a file from the beginning is an exceedingly time-con-suming task. It may take three months or more of initial operations anal-sis to determine areas requiring support. Having defined the general purpose and content of a file, three or four months of detailed analysis are required to establish the file format, a dictionary of terms, and to es-tablish a suitable file vocabulary. General coordination with all con-cerned parties of draft file specifications can consume one or two addi-tional months. Generation of the file at the data sources can require another two to three months-followed by a period of data consolida-tion, file generaconsolida-tion, and analysis of what went wrong, lasting perhaps another two months. Subsequent modification of reporting procedures
LARGE SYSTEMS 137 and a second generation phase to get a usable file brings the total time for file generation to between 14 and 17 months. The effort involved can run in excess of six man-years per file. Certain economies can be practiced by formatting data in machinable form from readily available manual files at the expense of additional resources required to generate the data.
Added economy can be had by borrowing data already put in machine form somewhere else.
As a result of the difficulty encountered in constructing useful data files, it may not be surprising that systems like USSTRICOM or NMCS have had equipment complexes and programming routines long before there was data of major operational significance in the system. Nor is it sur-prising that in the early phases of system operation where data develop-ment has only begun that the capability provided by the system can be easily matched by efficient manual methods.
At this point in time it would seem that there is no effective solution to the problem of data definition that does not require a sizable investment of time and resources in operations analysis.
The term "evolutionary design" has become the vogue recently, at least in the Washington area, to describe an orderly design progress that ad-vocates a learn-as-you-go policy in easy steps. Such a policy could be im-plemented by combining technical design activities employing the "new design" method with a substantial program of data definition.
Unfortunately, in some recent system developments, undue emphasis has been placed upon the uncertainty in command environments, and the tendency has been to use uncertainty as a rationale to defer planning for the systematic introduction of new capability. The result has been uncon-trolled system growth generally at a rate less than could be reasonably obtained.
Assuming that a more positive approach is adopted and applied, partic-ularly to command-system development, the major obstacles of uncertain environment and a resistance of the ADP support to rapid change in func-tion can be substantially reduced. Even so, systems would continue to be expensive and would continue to require long times to implement-not, however, out of proportion to the complexity of the functions they would be designed to perform.
Since the pressures for central management that motivate command-system development appear to be relatively unchanging, the only other apparent alternative to large-scale investment in complex systems for command lies in redefining some of the philosophy of centralized man-agement with the goal of reducing the complexity of system functions.
One example of a possible change in philosophy might be embodied in a system that keeps status on what subordinate element has what
re-sponsibility and what supporting system capability to carry it out. Such a file, if it reflected current status and contained adequate directories, could greatly ease the problem of executive problem definition and delegation of authority to execute assigned responsibility. It would imply that the tools to provide operational solutions to problems should be placed in the -hands of subordinates close enough to the problem to work on it
ef-fectively. Such a system would probably also require a major advance of management science to insure that the risk in operating in such a de-centralized mode was reduced to an acceptable minimum.
SUMMARY
In general, particularly for systems with military applications, costs are high, startup times are long, and functional performance often leaves something to be desired. However, the degree to which this is true varies markedly with the type of system under consideration.
Because of the characteristics exhibited by large military systems, their development has increasingly come under the scrutiny of high-level groups in government. These groups usually reflect user desires for high per-formance, short startup times, and lower costs. That these groups are not highly pleased with the development of large systems is apparent judging from the reductions in support of some of the programs, and the fact that most large-scale systems with major ADP support were initiated prior to 1960.
The apparent conclusion to be drawn is that large-scale systems that rely heavily on ADP support are bad. However, costs are not dispropor-tionate to the complexity of the functions desired, and startup times are not excessive when compared to similar times for completely· manual systems of similar complexity and scope.
Furthermore, performance is very different for different classes of system. Some of it has been very good. In those cases where performance is poor, much can be done to improve the situation. To insure ADP support responsive to uncertain and changing environments it is necessary that ADP programs be generalized as much as possible. Much techno-logical effort is currently being expended in this area.
Of far greater impact in the successful design of ADP support, the problem of data definition and acquisition must be approached as the highest priority item and successfully solved. It is this problem that lies at the core of system application. Recent actions by the Department of Defense have directed the user to take a greater role in the development of his system. To this proper enhancement of the user role, the technical implementer must join a major portion of his resources in a direct attack
LARGE SYSTEMS 139 on the problem through analysis and experimentation. It is possible that these steps may have to be coupled with fundamental changes in concepts, particularly in command applications, before long-range difficulties can be resolved.
In the current situation, problem definition in terms of the data to be used by the system, will be the barrier to increasing use of automation in large systems. It is likely that the near future will see the initiation of few if any truly large-scale command systems employir.g a high degree of ADP support. Instead, efforts will be focused on the search for simpler, less complex, faster to implement but possibly less adequate methods for solving system problems. Automated support, particularly in command systems, will be largely confined to Class I applications.
Mr. L. D. Earnest of the MITRE Corporation suggests that ADP may develop along the lines of a public utility. This would seem reasonable for systems of the Class I type. Large-system experience supports this view. People with definable jobs and data sources use the ADP service provided. Operators of the ADP facility provide for system growth on the basis of extrapolation of usage records. For applications where ADP is premature the user would like to wait until adequate data definition is accomplished. With ADP utilities he could wait, secure in the knowledge that the ADP support would be available when required.