ENGINEERING SYSTEMS MONOGRAPH The ESD Architecture Committee Edward Crawley, Olivier de Weck, Steven Eppinger, Christopher Magee, Joel Moses, Warren Seering, Joel Schindall, David Wallace, Daniel Whitney (Chair) THE INFLUENCE OF ARCHITECTURE IN ENGINEERING SYSTEMS March 29-31, 2004ENGINEERING SYSTEMS MONOGRAPH THE INFLUENCE OF ARCHITECTURE IN ENGINEERING SYSTEMS The ESD Architecture Committee Edward Crawley, Olivier de Weck, Steven Eppinger, Christopher Magee, Joel Moses, Warren Seering, Joel Schindall, David Wallace, Daniel Whitney (Chair) ABSTRACT The field of Engineering Systems is distinguished from traditional engineering design in part by the issues it brings to the top. Engineering Systems focuses on abstractions like architecture and complexity, and defines system boundaries very broadly. It also seeks to apply these concepts to the process of creating systems. This paper summarizes the role and influence of architecture in complex engineering systems. Using the research literature and examples, this paper defines architecture, argues for its importance as a determinant of system behavior, and reviews its ability to help us understand and manage the design, operation, and behaviors of complex engineering systems. A. INTRODUCTION Typical engineering design education focuses on specific aspects of design, such as the technical behavior of a set of elements interconnected in a certain way. By contrast, Engineering Systems focuses on a number of abstract concepts first because they provide a general framework for guiding the development of many diverse kinds of systems, so that these systems will provide the desired functions in the desired ways. Among these abstract concepts is that of system architecture. In this paper, we explore this concept and provide a number of ways of appreciating system architecture’s importance in both the practical aspects of system design and in the intellectual aspects of understanding complex systems from a variety of viewpoints. The paper begins with a definition of architecture and its influence on functional behavior, extra desired properties like flexibility and reliability (collectively called “ilities”), complexity, and emergent behaviors. Architectures are not static but instead evolve over long periods as technologies mature. They also evolve during the normal course of designing an individual system. These evolutionary patterns are useful in understanding architecture’s importance. The paper next provides several examples of architectures and illustrates how architecture affects the way systems are designed, built, and operated. The examples include aircraft, automobiles, infrastructures, and living organisms. The importance of architecture is framed in three domains of importance: as a way to understand complex systems, to design them, to manage them, and to provide long-term rationality by means of standards. The abstract concepts of modularity and integrality are shown to be useful for categorizing systems and illustrating how architectural form can influence important system characteristics. Several contrasts are noted between relatively small, deliberately designed products and evolutionary, less-managed large infrastructures. Architecture’s ability to influence the functions and allied properties of systems is shown to extend to robustness, adaptability, flexibility, safety, and scalability. Examples from recent research are given to show how some of these properties might be measured using network models of particular architectures. 1ENGINEERING SYSTEMS MONOGRAPH Finally, the paper identifies a number of important near- and long-term research challenges regarding the potential for understanding architecture to the point where a system’s behaviors can be completely determined. Among the barriers are complexity, bounded human rationality, and human agency. B. WHAT IS SYSTEM ARCHITECTURE? System architecture is an abstract description of the entities of a system and the relationships between those entities. Architecture is important in most technical fields, including not only civil architecture of buildings but of physical products, software, computer networks, large engineering systems, and infrastructures. The architecture of a system has a strong influence on its behavior. Every system has an architecture. Architectures may arise in the process of deliberate de novo design of a system; by evolution from previous designs with strong legacy constraints; by obeying regulations, standards, and protocols; by accretion of smaller systems with their own architectures; or by exploration of form and behavioral requirements via dialogue between users and architects, to name a few known mechanisms. While natural architectures may hold lessons for us, including the influence of evolution under constraints, we are mainly concerned here with man-made architectures of complex engineering systems. Man-made system architectures are created as part of the process of creating and designing systems. These systems are intended to have certain primary functions, plus other properties that we call “ilities:” durability, maintainability, flexibility, and so on. The primary functions have immediate value while the ilities tend to have life-cycle value. Like the ilities, the architectures themselves are long-lived either because they determine the design of several generations of products or because the resulting systems are themselves long-lived. In most cases, it is very challenging to design a complex system that achieves all of its primary functions and all of its ilities. In some instances one has to resolve tradeoffs between desirable properties for the short term versus desirable life-cycle properties. An example is the life-cycle property of extensibility, which might require including interfaces for future system elements that are not present in the original version. Such interfaces must be designed, will generally require additional resources, and might increase initial system complexity. The benefits of such architectural decisions are uncertain and might only be realized in the future, or not at all. Methods for evaluating uncertain events and providing for them in advance are discussed in De Neufville (2004). Some systems, such as familiar products of industry (cars, aircraft, computers) are designed according to a deliberate process that includes carefully thinking through what their architectures should be,