Preface

Software architecture is an important field of study that is becoming more important and more talked about with every passing day. Nevertheless, to our knowledge, there exists little practical guidance on managing software architecture in a real software development organization, from both technical and managerial perspectives. This book has emerged from our belief that the coupling of a system's software architecture and its business and organizational context has not been well explored.

Our experience with designing and analyzing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products). These requirements dictate the system's performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect.

In this book we demonstrate this coupling of software architecture and corporate context through the use of case studies drawn from real systems. Our examples include the following situations:

• The desire to share documents quickly and easily within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web.

• The extreme safety requirements of air traffic control led one company to build a system around an architecture for achieving ultra-high availability.

• The distribution of the subsystems of a flight simulator to remotely located developers led to an architecture geared to enable smooth integration of these subsystems.

• The need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to build a set of complex related software systems as a product line.

• The need to standardize architectural approaches across organizations and in the community at large led to infrastructures such as J2EE and EJB.

These and other case studies show that software architectures flow from the requirements of organizations and their business models, from the experience of the organization's architects, as well as from the prevailing design climate.

In addition, we show how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence the way other products are built. Certainly the case study about the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness, less thought was given to accessibility of data, and security was the concern of only a few organizations, typically financial institutions and government agencies.

Our book is aimed at software professionals-the people who design and implement large software-intensive systems, the managers of software professionals, and the students who are hoping to become software professionals.

We believe that a software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. Because its architecture appears early in a product's lifetime, getting it right sets the stage for everything to come-the system's development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, compared to other development activities, analyzing architectures is inexpensive. Thus, architectures give a high return on investment because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.

We also believe that re-use is achieved best within an architectural context. But components are not the only artifacts that can be re-used. Re-use of an architecture leads to the creation of families of systems, which in turn leads to new organizational structures and new business opportunities.

We devote a large percentage of this book to presenting real architectures that were designed to solve the real problems of real organizations. We chose the cases presented here to illuminate the types of choices that architects must make to achieve their quality goals and to illuminate how organizational goals affect the final systems.

In addition to the case studies, this book offers a set of techniques for designing, building, and evaluating software architectures. We look at techniques for understanding quality requirements in the context of an architecture, and for building architectures that meet these quality requirements. We look at architecture representation and reconstruction techniques as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architecture's fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems. These systems range up to millions of lines of code and are large-team, multi-year development efforts.

Although we discuss business issues throughout the book (for example, an architecture's effects on an organization's ability to compete in a market or a product family's time-to-market), we present this material without going into great depth on the business issues, and without business jargon. We are, after all, software engineers. We present the technical sections of our book in more depth. These sections represent current work in the field of software architecture-the point where research meets practice. The case studies illuminate these technical foundations, and show how they are realized in practice. To benefit from the lessons illuminated by the case studies, you will need a reasonable background in computer science, software engineering, or a related discipline. However, we have written them in such a way that you will not need expertise in the application domain from which the case study was drawn. For example, you do need not be a pilot to understand either the air traffic control system or the flight simulation case studies.