even likely that object-oriented programming and modular designs consistent with the HLA will make it possible for future systems akin to the RSAS to have long useful lives. This, indeed, is what is hoped for in the JWARS effort. Whether that is achieved depends on the intensity of devotion to keeping the JWARS effort an “open architecture” that can readily accommodate alternative modules and, thus, evolve if newer and better representations emerge of important objects or processes. The panel's experience has consistently been that day-to-day and economic pressures are almost always in favor of relatively monolithic, not extremely modular, constructions. The reasons are apparent to anyone who has built computer programs with more concern about speed of completion, run-time speed, and “straightforwardness ” than about expandability, reuse, modifiability, and so on. This has not changed. Another factor is DOD's frequent emphasis on agreed databases and configurational control, sometimes at the expense of quality. The Department of the Navy should establish a continuing policy of arguing for the modular assembly-oriented features of JWARS and JSIMS, and increase the emphasis on such matters in more Navy-and Marine-specific models like NSS.


Despite the theoretical and practical strength of modern model-building concepts and technology, we note that it is an unproved hypothesis that such reusability will be meaningful and sufficiently low-risk to be used in distributed analysis. It would not be surprising if cross-organization model confederations used in distributed simulation 20 years from now were as untrustworthy and impenetrable as large monolithic models are today—when used for tradeoff analysis and other complex tasks. On the other hand, model confederations have already proved useful, for both training and analysis, in a variety of situations. 4 Generalizations are dangerous, and much depends on how DOD manages its M&S in the years ahead.

Another caution is that building-block approaches have their limitations. There are costs associated with having a system with too many choices, building blocks, and features. In principle, such a system may be able to serve many different masters, with each assembling the system they need, but in practice the system may be difficult to comprehend and ponderous—especially when attempting to serve applications across domains with different concepts, purposes, terminology, and measures of effectiveness (e.g., training, test-and-evaluation, and force planning). As a result, there will continue to be demands for specialized systems with only moderate flexibility. The one-system-serves-all concept should be viewed with considerable suspicion.


Examples of successful use of confederations were given in a recent minisymposium (MORS, 1997). See, for example, the paper by Kent Pickett of the Army's TRADOC.

The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement