Software Architecture in Practice

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.\ What's New in the Second Edition\ Our goals for this second edition are the same as they were for the first, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and our new understanding both through new chapters and through strengthening the existing chapters. Also, the writing of this second edition has been strongly influenced by several other books that we have collectively authored since the publication of the first edition—Documenting Software Architectures, Evaluating Software Architectures: Methods and Case Studies, and Software Product Lines: Principles and Practice. The creation of these books, along with other technical and research activities, has greatly influnced us in developing this book. This second edition reflects the fact that architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition.\ Architecture analysis has developed into a mature field with industrial-strength methods—reflected here by a new chapter in Part Three about the Architecture Tradeoff Analysis Method (ATAMSM). Many industrial organizations have adopted the ATAM as a technique for evaluating software architectures.\ Architecture design has also had major developments since the first edition. The capturing of quality requirements, their achievement through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve them are all discussed in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and the Attribute Driven Design Method (ADD).\ Architecture reconstruction, or reverse engineering, is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project or as an analysis project, or as input into a decision regarding what to use as a basis for reconstructing a system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context, but in this edition the topic merits its own chapter.\ Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected here with all-new diagrams. More important, an understanding of the kind of information to capture about an architecture, beyond which notation to use, has emerged. A new chapter covers architecture documentation.\ The application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. This chapter reinforces the link between architecture and an organization's business goals, in view of the fact that product lines (based around a software architecture) can enable order-of-magnitude improvements in cost, quality, and time-to-market.\ In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend in our updated chapter on the World Wide Web by using Web-based examples in the chapter on the ATAM and the chapter on building systems from components, by replacing the case study on Common Object Request Broker Architecture (CORBA) with one on Enterprise JavaBeans (EJBs), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians.\ Finally, we have added a chapter that looks more closely at the financial aspects of architectures. In this chapter, we introduce a method—the Cost Benefit Analysis Method (CBAM)—for basing architectural decisions on economic criteria, in addition to the technical criteria that we discussed previously.\ As in the first edition, we use the Architecture Business Cycle (ABC) as a unifying motif. All of the case studies are described in terms of the quality goals that motivated the system's design and how the system's architecture achieves those goals.\ In writing the second edition, as with the first, we were very aware that our primary audience is practitioners, and so we have focused on material that has been found useful in many industrial applications as well as what we expect practice to be in the near future.\ We hope that you enjoy reading this second edition at least as much as we enjoyed writing it.\ 0321154959P03252003

PrefaceAcknowledgmentsReader's GuidePt. 1Envisioning Architecture1Ch. 1The Architecture Business Cycle3Ch. 2What Is Software Architecture?19Ch. 3A-7E Avionics System: A Case Study in Utilizing Architectural Structures47Pt. 2Creating an Architecture69Ch. 4Understanding Quality Attributes71Ch. 5Achieving Qualities99Ch. 6Air Traffic Control: A Case Study in Designing for High Availability129Ch. 7Designing the Architecture153Ch. 8Flight Simulation: A Case Study in Architecture for Integrability175Ch. 9Documenting Software Architectures201Ch. 10Reconstructing Software Architectures231Pt. 3Analyzing Architectures261Ch. 11The ATAM: A Comprehensive Method for Architecture Evaluation271Ch. 12The CBAM: A Quantitative Approach to Architecture Design Decision Making307Ch. 13The World Wide Web: A Case Study in Interoperability327Pt. 4Moving from One System to Many351Ch. 14Software Product Lines: Re-using Architectural Assets353Ch. 15CelsiusTech: A Case Study in Product Line Development369Ch. 16J2EE/EJB: A Case Study of an Industry-Standard Computing Infrastructure401Ch. 17The Luther Architecture: A Case Study in Mobile Applications Using J2EE427Ch. 18Building Systems from Off-the-Shelf Components453Ch. 19Software Architecture in the Future477Acronyms485References489Index495