Open Systems Architecture - Both Boon and Bane

Abstract

As with every major social revolution, the advent of the digital age was accompanied by growing pains. Many of the methods used in the first few decades were ultimately rejected for better and more proven approaches. Complex systems such as aircraft avionics or military weapons control systems are no longer the purview of the omniscient hardware guru or software wizard. These mystics have been replaced by processes that improve productivity and enhance long-term maintainability. However, in most cases application of these processes produces its own set of problems This does not necessarily mean that the practice should be discontinued; the perfect solution may not exist. It is important that system architects select those practices that best meet their specific goals, while accounting for the associated problems. Over the past several years managers have come to accept as axiomatic that the use of systems reduces cost, decreases schedule, and eliminates risks to a program. However, the term, open systems invokes a variety of interpretations. To some it implies no proprietary components. To others it implies adherence to documented standards. Still others see it as implying plug-and-play features. This paper investigates several observed interpretations of the meaning of open systems architecture. Each interpretation exhibits both positive and negative aspects, which should be considered when architecting requirements for a specific system. Particularly for complex or long-life programs such as the NASA's space exploration vision, there is a threshold beyond which the benefits of increased openness are outweighed by the associated costs. This paper concludes with a recommendation regarding the optimal placement of the architecture threshold line for complex, long-life programs