bull; A thorough introduction to all aspects of software architecture bull; Shows how the knowledge and application of software architecture can help an organisation achieve the quality goals of its systems bull; The field of software architecture continues to grow, and this book is the leading introduction

Len Bass is a senior member of the technical staff at the Software Engineering Institute (SEI) Paul Clements is a senior member of the technical staff at the SEI, where he works on software architecture and product-line engineering Rick Kazman is a senior member of the technical staff at the SEI. He is also an associate professor at the University of Hawaii

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 substa