Customer Reviews

Software Architecture in Practice

5 star:		(7)
4 star:		(6)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

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"!

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!

Some would have trouble describing the discipline of Software Architecture in a concise sentence... Writing a book about it is a bigger challenge.

What I like about this book is that it spells out succinctly some of the principles that software architects should adhere to... and then identifies why they sometimes should not. The tradeoffs, while not discussed in the light of a common problem, but mostly as a comparison between two or more 'reference architectures', become clear once the reader can frame the problem in a way that applies to her own architectural dilemmas.

On the other hand, the book now shows its age. While CORBA makes for a good case study, most software architects would benefit from a Web-Services study, and the patterns that are being used there.

Overall, a good book but I would recommend you flipping through it to figure out if it would help you in your day-to-day activities - or whether another Software Architecture book is more suitable.

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?

The book is basically good. SAAM is useful. However, I am at a loss to understand why the authors have chosen to totally ignore UML, which is (and was at the time of publication) the de facto standard for representing software architecture. They have instead represented architectures in their own non-standard, which the reader is forced to learn to understand their diagrams.

UML is now as fundamental a piece of knowledge to the software architect as schematics are to the electrical engineer, and for the same reason - it is a common language of discourse, and is supported by the available tools. I urge the authors to publish a second edition with UML substituted for the ad-hoc diagrams.

This book has only a few hundred pages. It took me still two months to read through it. Every sentence is loaded with information. A lot of important statements are stuffed into lists and tables. This gives the book excellent reference qualities and this makes the book quite a hard read, especially after work.

The content is relevant, clearly described and trustworthy. It has very little references to alternative views on the subject.

I am still looking for a good introductory fat book on software architecture.

What is arguably the best analogy to the creation of the large, modern software product is the construction of the great pyramids of Egypt: any error made in laying down the lower layers was magnified many times over when the additional layers were added. The placement of even a single component required the coordinate actions of many workers. Large detailed plans were necessary before the first block could be laid and while no precise deadline existed, there was a general one. Finally, despite their impressive size, the pyramids were built by applying simple components while following a well-understood pattern for integration.
Therefore, as so many people are now pointing out, software engineers can learn much from the masters of construction.
Architecture (architorture to students of the craft) is a very difficult area to master. The human mind processes information based on patterns, but much of that efficiency is based on experienced patterns, and abstractions rarely come easy even to the prepared mind. In this book, the authors do a great deal to assist "open minds" in preparing to understand and use architectural patterns.
To present their ideas, the authors coined the phrase, "Architecture Business Cycle" (ABC). This phrase is designed to describe the entire process, from the initial itch on the back of the brain, to the influence of the architecture of one product in succeeding generations of products. Only when the consequences to future generations of software are included can we truly say we are describing the complete software life cycle.
The approach used is a combination of explanation and case studies. Seven of the nineteen chapters are case studies that generally are well-done examples of the material. The core of the book, however, is the development of the steps in the construction of the ABC. The first step is the creation and analysis of a specific architecture. To perform the analysis, the authors put forward the Software Architecture Analysis Method (SAAM), a scenario-based method of evaluation. This technique is also one of the components of an architecture-review process.
After the architecture is developed, it is time to create an equivalent system based on the design. To do that, a symbolic notation is needed. While there is some time spent on Architecture Description Languages (ADLs), this is one topic that should have been expanded. Without a common language that has a high degree of precision, there is a great deal of room for potential error. The analogy or metaphor that clarifies a concept for one person makes it less comprehensible for others. An example of an ADL is presented, but seven pages containing diagrams is not enough to do more than spark interest or confusion.
The final area concerns the reuse of components and architecture. Two chapters are devoted to this topic, one on reuse within an organization and the other on reuse within the community. Within an organization, the emphasis is on the other software product line-a series of products in both parallel and sequential development. Creating a "reasonable" match to a consumer's requirements in the software development equivalent of real time is achievable only if there is an extensive stock of well-designed components that work and play well with each other. The only way to achieve this is to make such behavior part of the fundamental design. In the modern era of global competition, exposing your architectural designs to the world might seem to be a poor business practice. However in many areas this is not the case.
Software developers can learn a great deal from the construction engineers of the ancient world. When planning a complex structure, the medieval architect commonly attacked the problem from a multigenerational perspective. Knowing the project would not be completed for decades, the initial architectural plans included the passing of the necessary legacy knowledge down to the later generations of planners and builders. Only then could there be a guarantee of completion and long-term viability. The ABC as put forward in this book is one way the computer industry can approach problems from the same perspective.

Published in Journal of Object-Oriented Programming, posted with permission.

The book is well written and quite comprehensive on the subjects covered. It provides an extensive coverage of topics around software architecture and explains the relationship between software architecture, architectural styles, systems, etc. It also includes a substantial number of novel discussions on issues such as architectural qualities, architecture-based system development, and architecture-based reuse. It uses extended examples to illustrate the points being made.

The only thing I didn't like was the lack of a more formal approach to presenting the subject matters.

This book offers a very good overview of this important discipline as well as a sound introduction into state-of-the-art architecture-centered engineering.

Good structure, well chosen case studies and a good coverage of all relevant topics.

I think this is a must-read for every decent software engineer.

The authors examine 7 case studies representing 37% of the 19 chapters. "The software architecture of a program or computing system is the structure(s) of the system, which comprise software components, the externally visible properties of those components, and the relationships among them (pg 23)." Describes common structures for example module structure, conceptual or logical structure, process or coordination structure, physical structure, uses structure, calls structure, data flow, control flow, and class structure. Explains how choosing architecture influences the achievement of quality attributes. Illustrates architectural styles such as batch sequential, pipes & filters, event systems, repository, virtual machine, and object oriented.