[19]   

Current and prior work in the area of Information Warfare focuses on the deterance and detection of intrusions that compromise complex systems. The next step is to evolve the system to compensate or at least provide some functionality once an intrusion is detected. In a complex C3I system this is a complex task. We are working on a portion of this problem. We are in the early stages of designing a means for an OSA to evolve to a new functional state in the event of an Information Warfare attack.

Ad hoc approaches to software evolution have not been successful for evolving large, complex systems because they do not cover all possible ways in which a large system can change, do not interact with each other, do not support reasoning about the effects of local changes on other parts of the system, and do not scale.

The overall goal of our project is to make it possible to evolve complex software systems far more easily than can be done today. We believe the key is to base software evolution on architectural principles, since this allows reasoning about the possible kinds of evolution and the effect of changes on other parts of the system.

Software evolution moves a system from one legal configuration to another legal configuration. Evolution of a software system must be safe, correct, and orderly. The effect of a change on the system's functionality and performance should be predictable. The effort to change something should correlate to the perceived value of the change, and change should not ripple to seemingly unrelated parts of the system. Finally, change must be supported by tools to make it tractable and to ensure that it is done correctly according to the change management policies.

The requirement that evolution move the system between legal configurations implies that there is a description of what constitutes a legal configuration. In a sense, this is similar to the formalisms for transaction management; proofs of correctness rely on assumptions of consistent states.

No such characterizations of legality can be made in general. Further, even if it were possible to formally specify correctness conditions for a particular application architecture, any evolution results applicable to it would not map easily to a different application architecture. What is needed is a simple, canonical infrastructure architecture on which application architectures can be built. Since many of the evolution concerns are not application-specific, they could be dealt with at the infrastructure level and their cost amortized.

In the last five years, a new class of software architecture, Object Services Architectures, has begun to provide a more principled basis for understanding how to build large-scale, configurable information systems. OSAs are based on an object bus and attached object services. They are conceptually simple; are open and extensible; can be based on component standards; are understandable and scalable; and appear to be configurable and evolvable since they can accommodate a variety of possible binding times. Based on our experience, OSAs appear to explain how higher level information systems including OODBs, Relational DBMSs, Repositories, Workflow Systems, and KBMSs can be configured from components.

In spite of substantial investment in OSA architectures, they are still relatively new. Deployed OSA systems are immature and the academic research community lags in OSA R&D so that OSA architectural properties are not yet well understood. Without additional research, OSAs could fail to reach their potential as scalable backplanes for DoD and commercial information infrastructure.

OSAs lack a solid theory of what constitutes a legal static configuration except under the most trivial circumstances. In general, an OSA simply allows services to be connected together and it is up to the application developer to have the right services exchange messages. This lack of constraints in the architecture model substantially weakens its utility, since an architecture not only enables, it also precludes certain kinds of "bad" organizations. Specifically lacking from the static OSA model are theories of replication of services, descriptions of how to federate multiple similar services into a combined service (e.g., several version managers managing different parts of a version space), conditions under which multiple policies for the same service can co-exist without creating a centralized control point service (e.g., different concurrency or persistence policies), and how to characterize the orthogonality of services.

Without the ability to assert that a particular (non-trivial) application configuration is legal with respect to an OSA model, there is no possibility of proving the correctness of a move between two legal states. Thus, our first task is to complete the static theory of OSAs by adding constraints and techniques as discussed above.

Once a static model of OSAs has been developed, a dynamic model of OSA evolution becomes possible. One of the hardest and least understood aspects of managing change in a complex system is that the system is necessarily built using many tools, each of which has a different model of evolution and has no knowledge of any other tool's model. Existing change management models do not comprehend that change management in the large requires coordination of multiple, specialized change managers. Either as such, they try to control the world and fail, or they manage only one aspect of change and ignore others.

Back to the Table of Contents
   [19]