Software Architecture in Practice (2nd Edition) (Hardcover)

~ (Author), Paul Clements (Author), (Author)

Editorial Reviews

Product Description

This award-winning book, substantially updated to reflect the latest developments in the field, introduces the concepts and best practices of software architecture--how a software system is structured and how that system's elements are meant to interact. Distinct from the details of implementation, algorithm, and data representation, an architecture holds the key to achieving system quality, is a reusable asset that can be applied to subsequent systems, and is crucial to a software organization's business strategy. Drawing on their own extensive experience, the authors cover the essential technical topics for designing, specifying, and validating a system. They also emphasize the importance of the business context in which large systems are designed. Their aim is to present software architecture in a real-world setting, reflecting both the opportunities and constraints that companies encounter. To that end, case studies that describe successful architectures illustrate key points of both technical and organizational discussions. Topics new to this edition include: *Architecture design and analysis, including the Architecture Tradeoff Analysis Method (ATAM) *Capturing quality requirements and achieving them through quality scenarios and tactics *Using architecture reconstruction to recover undocumented architectures *Documenting architectures using the Unified Modeling Language (UML) *New case studies, including Web-based examples and a wireless Enterprise JavaBeans (EJB) system designed to support wearable computers *The financial aspects of architectures, including use of the Cost Benefit Analysis Method (CBAM) to make decisions If you design, develop, or manage the building of large software systems (or plan to do so), or if you are interested in acquiring such systems for your corporation or government agency, use Software Architecture in Practice, Second Edition, to get up to speed on the current state of software architecture.

From the Inside Flap

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

Our experience with designing and reviewing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and also in its ultimate success or failure. Systems are built to satisfy an organizationis requirements (or assumed requirements in the case of shrink-wrapped products), and these requirements determine the extent to which a system must meet performance targets, be highly available, interoperate with other systems, or be designed for long lifetimes. These properties of a system are constrained by the systemis software architecture; or, to put it another way, the desire to achieve these properties influences the design choices made by a software architect.

In this book we demonstrate this coupling through the use of case studies drawn from real systems, including the following: In Chapter 7, we show how the desire to quickly and easily share documents within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web. In Chapter 11, we discuss how the extreme safety requirements of air traffic control led one company to build a system around an architecture for achieving ultrahigh availability. In Chapter 14, we describe how the distribution of the subsystems of a flight simulator to different remotely located developers led to an architecture geared to enable the easy integration of these subsystems. In Chapter 16, we explain how the need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to economically build a set of complex, related software systems as a product line.

These and other case studies show how the architectures flow from requirements of organizations and their business models, from the experience of the organizationis architects, and from the prevailing design climate.

In addition, we discuss how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence how other products are built; certainly, the case study of 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.

This book is aimed at the software professionalothe person designing and implementing large software-intensive systemsoand at the managers of software professionals. It does not contain, for example, detailed financial justification for using a software architecture, for doing early architectural analyses, or for investing in a product line approach to building software. We provide only anecdotal evidence to support the claims that these pay off, although we passionately believe they do.

A software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. This is because an architecture appears early in a productis lifetime. Getting it right sets the stage for everything to come in the systemis life: 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, analyzing architectures is inexpensive, compared with other development activities. Thus, architectures give a high return on investment partially because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.

We also believe that reusable components are best achieved within an architectural context. But components are not the only artifacts that can be reused. Reuse of an architecture leads to the creation of families of similar systems, which in turn leads to new organizational structures and new business opportunities.

A large percentage of this book is devoted to presenting real architectures that were designed to solve real problems in real organizations. We chose the case studies to illustrate the types of choices that architects must make to achieve their quality goals and to show 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 description languages as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architectureis 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, multiyear development efforts.

We have also provided a visual language for describing software architectures that contains enough expressiveness to describe both procedural and object-oriented systems and enough generality to describe systems at any granularity: a division of functionality, a set of software structures, a set of hardware structures, or any combination of these. Although a visual notation is not, in itself, documentation of an architecture, it is an integral part of such a documentation. One of our complaints with the state-of-the-practice in architecture today is the vagueness of architectural descriptions. We hope that the visual language described here is a contribution to the field, aimed at increasing the effectiveness of architectural documentation.

The book targets software professionals, or students who have knowledge and experience in software engineering, and we anticipate the following three classes of readers:

Practicing software engineers who wish to understand both the technical basis of software architecture and the business and organizational forces that are acting on them Technical managers who wish to understand how software architecture can help them to supervise the construction of systems more effectively and improve their organizations Students in computer science or software engineering who might use this book as supplemental reading in a first or second software engineering course

Although business issues are discussed throughout the book (for example, how an architecture affects an organizationis ability to compete in a market or how the architecture underlying a product family affects time to market), we present this material without going into the business issues in great depth and without using business jargon. We are, after all, software engineers. The technical sections are presented in more depth. These sections represent current work in the field of software architectureothe point where research meets practice; they are the philosophical foundations of the book. The case studies illustrate these technical foundations and show how they are realized in practice. However, we have written the case studies in such a way that expertise in the application domain from which each case study was drawn is not required. You will not need to be a pilot to understand either the air traffic control system or the flight simulation case studies. However, you will need to have a reasonable background in computer science, software engineering, or a related discipline to benefit from the lessons of the case studies.

One final note on the organization of the book. Software Architecture in Practice is not intended to be a prescriptive method for architectural design. In fact, we believe that it is impossible to satisfactorily create such a prescriptive design method. Any design involves trade-offs: Modifiability affects performance, security affects modifiability, scalability affects reliability, and everything affects cost. Any prescriptive method implicity or explicitly assumes that some of these qualities are more important than others and guides users toward the maximization of that goal. Our feeling is that although such an approach may be appropriate in a specific domain, it cannot possibly work in general. Quality requirements are different from organization to organization and from year to year.

By way of contrast, we offer a toolbox approach to design. We believe that different architectural tools and techniques are appropriate for different situations and different quality goals. No single technique will ever suffice. So, we present a number of different architectural tools (layering, multiple views, patterns, blackboards, and so forth) and techniques (analysis methods, integration strategies, engineering principles) and illustrate their usage in different business and technical contexts.

Not surprisingly, most of the case studies use a mix of tools and techniques because they were chosen to illustrate how software architecture was the foundation for a successful system. These systems were successful precisely because they chose the right tools and implemented them using the right techniques. Anything less would not have resulted in a successful system, as we hope to persuade you in the coming pages. 0201199300P04062001 --This text refers to an alternate Hardcover edition.

See all Editorial Reviews

Product Details

• Hardcover: 560 pages
• Publisher: Addison-Wesley Professional; 2 edition (April 19, 2003)
• Language: English
• ISBN-10: 0321154959
• ISBN-13: 978-0321154958
• Product Dimensions: 9.4 x 6.5 x 1.6 inches
• Shipping Weight: 2.5 pounds (View shipping rates and policies)
• Average Customer Review: 4.2 out of 5 stars  See all reviews (26 customer reviews)
• Amazon.com Sales Rank: #87,303 in Books (See Bestsellers in Books)

  Popular in these categories: (What's this?)

  #40 in	Books > Computers & Internet > Hardware > Microprocessors & System Design > Computer Design
  #64 in	Books > Computers & Internet > Hardware > Design & Architecture

• This item is part of The SEI Series.

Customer Reviews

Most Helpful Customer Reviews

40 of 41 people found the following review helpful:

5.0 out of 5 stars Practical, readable, excellent, November 28, 2000

By	Peter S. Hamlen "Rooftop gardener" (Brooklyn, NY United States) - See all my reviews (REAL NAME)

This review is from: Software Architecture in Practice (Hardcover)

I found this volume to be extremely useful. It contains very insightful commentary on what architecture is (a term that I find is misused a lot), what architecture affects, and how to evaluate the qualities of an architecture.

Two of their best insights for me:

* Architecture affects the organization of the company/business unit. (In my company, we didn't realize this and we failed to create an organization that could support the architecture.)

* Virtually any architecture can accomplish the functional needs of a system - what differentiates architectures are how they provide the essential qualities (performance, modifiability, maintainibility, etc.) to the product.

The book is strongly based in the real-world, with practical examples. I never felt they were straying into "theorectical" land.

I also bought "Applied Software Architecture" but didn't like it nearly as much - I highly recommend "Software Architecture in Practice"!

34 of 38 people found the following review helpful:

5.0 out of 5 stars excellent, November 27, 1999

By	Luis Alcibiades Espinal (Hialeah Gardens, FL USA) - See all my reviews (REAL NAME)

This review is from: Software Architecture in Practice (Hardcover)

This book is my bible with regards of software architecture. In previous S.E. courses, I heard about software architecture, but the notion never quite sank on my skull; perhaps because the notion itself required a course on itself, or in this case, a book. A minor problem is that the book does not use UML; however, the diagrams the authors use are easy to understand. More importantly, I find the narrative is as good as the diagrams themselves. I almost never have to look at the diagrams to understand the notions. Tumbs up to the authors!

27 of 30 people found the following review helpful:

5.0 out of 5 stars A Bible for Software Architects, November 25, 2003

By	ART SEDIGHI (Old Bethpage, NY United States) - See all my reviews

Being a Software Architect, I can certainly appreciate the work that the authors of this book (L. Bass, P. Clements, R Kazman) have put into this book. Software Architecture in Practice is probably the best book that I have read on the theory and practice of architecture design and software engineering. There is no fair way for me to review this book as it is PACKED with useful information from beginning to the very end. It has a combination of high-level architectural concepts tailored with best software engineering practices. It is not a complete book on software engineering, but it wasn't meant to be - it's meant to cover a very specific topic in software engineering and it does so extremely well. It is a text in which the concepts architecting software applications, evaluating architectures thru various methods, and case studies of major leaps in software architecture have been very well described; depicted and well evaluated. The book is written from an architect's point of view, and it shows how an architect or a group of architects can make or break an organization, and what they need to do in order to be successful. The authors of this book explain why simply architecting something is not good enough and lots of work needs to be done before and after the architectural phase to ensure the quality and the success of the project. This aspect of the book is simply priceless.

The author start by describing software architecture as:

"The Software Architecture of a program or computing system is the structure or structures of the system, which compromise software elements, the externally visible properties of those elements, and the relationships between them."

Throughout the book, the author used this definition to describe various aspects of architecture. One of the methods/techniques that the author uses is called the Architecture Business Cycle (ABC). ABC is method of realizing the "things" that influence the architect and in-turn the architecture - known as the circle of influences. This concept, ABC, is used for all the case studies mentioned in this book:

· A case study on a system that have extreme safety requirements - the Air traffic control.
· A case study on a system with high level of distribution of its subsystems - A flight simulator
· A case study in which it was essential for the organization to be able to share documents instantaneously.
· A case study on an organization where one architecture lead to a product line of applications
· A case study on the need to standardization of architectural approaches across organizations and the community - J2EE and the EJB.

For each case study, the authors depict its ABC and give the reader the reason, business reason, that this project got started to begin with. The reader then walks thru a series of decision-making steps that led to the architecture that was finally chosen. The drivers of the project, the business reason, the architect[s], and the organization are all linked and the authors go into a GREAT DETAIL on how this link can influence the final design.

Architecture Tradeoff Analysis Method or ATAM is a new topic that is added to the second edition of the book. ATAM is a structured method of evaluating architectures.

"It results in a list of risks that the architecture will not meet its business goals"

The authors start by describing the roles and responsibilities of people involved in ATAM, and the output artifacts that ATAM will produce when completed:

· A Concise presentation of the Architecture
· Articulation of the business goals
· Quality requirements in terms of collection of scenarios
· Mapping of architectural decisions to quality requirements
· A set of identified sensitivity and tradeoff points
· A set of risks and non-risks
· A set of risk themes.

The process of ATAM is depicted next in which there are a total of 4 phases:

1) Partnership and preparation: the key project decision makers informally meet to work out the details of the ATAM process.
2) Evaluation phase - the long evaluation process of the architecture with the same project decision makers as in previous phase
3) Evaluation phase, continued - this time the stakeholders are present
4) Follow up - the stakeholders and the evaluation team meets again to follow up.

The process is described very well and examples forms are shown in the book that can be used for your evaluation process. The great thing about this chapter and how it's written is the way that the ATAM process is presented. It is almost like a checklist that the architects need to follow. Very easy to read and follow. The inputs of every phase are clearly identified, and the description of the output is depicted rather clearly. The chapter ends with yet another case study that shows the "theory" just presented. The authors close the chapters by having the following comments about this book:
· ATAM is not an evaluation of Requirements, but only the architecture
· ATAM is not a code evaluation
· ATAM does not actually involved system testing
· ATAM is not a practice instrument, but identifies possible areas of risk within the architecture.
The ATAM is followed by another very well written topic on CBAM (Cost Benefit Analysis Method). This chapter is also new in this edition, but I will leave the details of this chapter for the reader. I like the ATAM method more than the CBAM, because it seems simpler to me.
All and all, the authors in this book did a fantastic job in writing this book. This book is packed with useful information for architects, project leads, and even technical managers.