Rating: 
Summary: A Bible for Software Architects
Review: 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.
Rating:
Summary: A Bible for Software Architects
Review: 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.
Rating: 
Summary: More theoretical
Review: Contrary to the title, I found the book more on the theoretical side. Lots of classifications with questionable practical value. The examples are high-level ending up with more classifications. Same observation about the simplistic figures.
Chapter 13-The World Wide Web gives an introduction of the initial Web requirements, while Chapter 16-J2EE/EJB explains general ideas about EJB. My benchmark for an "solid" book, with somehow related topic, would be "Design Patterns" by Gamma,Helm,Johnson,Vlissides.
Rating: 
Summary: Good Undergraduate Text
Review: I appreciated the authors' "real world" sense in their discussions. They don't get overly religious about a documentation style and they emphasize the need for a holistic approach to understanding architecture's impact on the application and the organization (e.g. work assignments, organizational view, risk assessment, ATAM as a communication tool etc). I particularly liked their presentation on the building blocks of an architecture as well as their discussion on tactics. My only criticism, and the students' as well, were the study cases. They threw too much at the reader about specific projects (some which were never completed). I think there should have been a better balance on the type of applications as well. I do plan on using this text again for my class next year.
Rating:
Summary: Good Undergraduate Text
Review: I appreciated the authors' "real world" sense in their discussions. They don't get overly religious about a documentation style and they emphasize the need for a holistic approach to understanding architecture's impact on the application and the organization (e.g. work assignments, organizational view, risk assessment, ATAM as a communication tool etc). I particularly liked their presentation on the building blocks of an architecture as well as their discussion on tactics. My only criticism, and the students' as well, were the study cases. They threw too much at the reader about specific projects (some which were never completed). I think there should have been a better balance on the type of applications as well. I do plan on using this text again for my class next year.
Rating:
Summary: Practical, readable, excellent
Review: 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"!
Rating:
Summary: An excellent book on an increasingly important discipline.
Review: I too am somewhat disappointed with the lack of more formal treatment of selected aspects of various topics and issues. More concise and formal supplements to the well-written but sometimes verbose text would help clarify and solidify understanding of core concepts. I am certainly grateful that the authors didn't waste space on examples from 'the business world' and the 'financial environment'. The more interesting, challenging and critical problems are, and will increasingly be, elsewhere, especially in ever-larger and increasingly complex real-time communication and control systems applications.
Rating:
Summary: A must read if you are serious about software architecture.
Review: Likes, The articulation of the Architecture Business Cycle (ABC), a theme that runs through-out the book. The ABC is a holistic view of the business environment, architecture, the architect, and the development organisation. Discussions on Architecture Style. An overview of a Software Architecture Analysis Method (SAAM) for assessing the suitability of a candidate architecture. Numerous and insightful cases studies including, AE7-Avionics System, WWW, CORBA, air traffic control, flight simulation, and command-and-control systems. Dislikes, In digestible tables and check-lists. No cases studies from the financial environment. Where are the cases for banking, insurance and accountancy for instance?
Rating:
Summary: Good software architecture book
Review: My recent software engineering graduate course on software architecture relied mainly on this SEI text, along with several of the many SEI white papers posted on the SEI site, and such texts as Buschmann's Pattern Oriented Software Architecture (POSA) and Stelting/Maassen's Applied Java Patterns. Since the second edition of the text was available just two weeks after the start of the course, I decided not to purchase the first edition, and instead purchased the second edition. However, having used both editions for the course, I must say that the second edition is superior to the first even when only taking the architectural view notation into account (it uses UML rather than a cryptic, proprietary notation used in the first edition, although at this high of a level in modeling, UML sometimes disappoints as well). The addition of content from some SEI white papers to the text is also a benefit of the second edition. The text, regardless of the edition, is well written and very understandable.
Rating:
Summary: "In Practice" are the key words
Review: SAIP gave some useful insights into how to apply the most practical aspects of software architecture to projects. Rather than dwelling on the "pie in the sky" theories that are so abundant (but which are usually completely impractical in a company which needs revenue to survive), the authors give good practices to meet both architectural quality, and practical goals. They also give some fairly illustrative examples. What I didn't like about the book was that it doesn't present a complete approach to developing a software architecture. It outlines many different pieces of the puzzle of architecting, but doesn't do a good job of putting the complete puzzle together for the reader.
| 
