What do you think?
Rate this book
Applied Software Architecture
"Designing a large software system is an extremely complicated undertaking that requires juggling differing perspectives and differing goals, and evaluating differing options. Applied Software Architecture is the best book yet that gives guidance as to how to sort out and organize the conflicting pressures and produce a successful design." -- Len Bass, author of Software Architecture in Practice. Quality software architecture design has always been important, but in today's fast-paced, rapidly changing, and complex development environment, it is essential. A solid, well-thought-out design helps to manage complexity, to resolve trade-offs among conflicting requirements, and, in general, to bring quality software to market in a more timely fashion. Applied Software Architecture provides practical guidelines and techniques for producing quality software designs. It gives an overview of software architecture basics and a detailed guide to architecture design tasks, focusing on four fundamental views of architecture--conceptual, module, execution, and code. Through four real-life case studies, this book reveals the insights and best practices of the most skilled software architects in designing software architecture. These case studies, written with the masters who created them, demonstrate how the book's concepts and techniques are embodied in state-of-the-art architecture design. You will learn how * create designs flexible enough to incorporate tomorrow's technology; * use architecture as the basis for meeting performance, modifiability, reliability, and safety requirements; * determine priorities among conflicting requirements and arrive at a successful solution; and * use software architecture to help integrate system components. Anyone involved in software architecture will find this book a valuable compendium of best practices and an insightful look at the critical role of architecture in software development.
432 pages, Hardcover
First published November 4, 1999
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 3 of 3 reviews
June 9, 2026
This book was published over fifteen years ago and has not aged as well as I hoped.,though the Siemens case studies still include some interesting observations.
Most but not all of the notation is well-formed UML but there some noteworthy variations, especially as regards to concurrent processes and occasionally the high-level diagrams disconcertingly dip into rather low-level details.
The authors propose four software architecture views and complement it with informal requirements grouped into organizational, technological, and product factors. The analysis of these requirements lead them to propose strategies to tackle software architecture feature and trade-offs. I find Bertrand Meyer’s PEGS (Project, Environment, Goals, and Systems) requirements taxonomy much clearer – Hofmeister at al’s organizational factors roughly correspond to Meyer’s Project requirements, technological factors to Environment requirements, and prodct factors System requirements. Meyer’s Goal requirements are incompletely included among organizational and product factors. The authors’ strategies are related to rationales for architectural decisions.
The authors’ four views for software architecture immediately reminds the readers of Phillipe Krutchen’s 1995 4+1 views model for software architectures. Krutchen’s model has been better accepted by software engineers and it is probable safe to say that Krutchen’s remains the dominant model today. Krutchen’s views seem to depend more clearly on different diagrams, while each of Hofmeister’s et al’s four views seems to float rather confusingly on overlapping kinds of diagrams.
Krutchen’s logical view is quite similar to Hofmeister’s et al’s conceptual view -they are both built on class and state diagrams, but the conceptual view also throws in object, component, and sequence diagrams to round out its explanation. Hofmeister at al’s module view (mainly based on package and componen diagrams) seems to straddle aspects of Krutchen’s process and development view – Krutchen’s process view may also depend on sequence, communication and activity diagrams, as well as package and component diagrams. Krutchen’s physical view, which tends to rely on deployment diagrams is roughly equivalent to Hofmeister et al’s execution view which relies not just on deployment diagrams but also on a non-UML standard process diagram -which is particularly suited to high-level real-time process documentation.
Hofmeister, Nord, and Soni present four case studies in software architecting which correspond to real-life Siemens product lines:
I would not recommend this book as a textbook for an introductory-level course on software engineering, software product-line engineering or software architecture. It could be an interesting challenge to critically analyze its proposals in the context of real-time, concurrent industrial-scale software systems.
A more positive review, written over ten years ago in 2004 by wiredweird can be found on the Amazon page for this book. A more negative one, written by Oliver Goldman in 2026, can be found at https://ogoldman.github.io/architects.... This review includes the following interesting and/or moot observations:...the book is based on observational study of software architecture at Siemens in the 1990s. If you are also an architect at Siemens and still employed building 1990s-era Siemens products—well, I was going to say this book is for you—but better advice would be to get a new job.
...substantial time is spent on organizing systems into modules, and the reader is told that modules are organized into layers. What they should say is that modules can be organized into layers, assuming a layered architecture […] Assuming that all systems are organized into layers is simply wrong.
...most of the examples feel far removed from multi-CPU, multi-core, cloud-based systems.
Most but not all of the notation is well-formed UML but there some noteworthy variations, especially as regards to concurrent processes and occasionally the high-level diagrams disconcertingly dip into rather low-level details.
The authors propose four software architecture views and complement it with informal requirements grouped into organizational, technological, and product factors. The analysis of these requirements lead them to propose strategies to tackle software architecture feature and trade-offs. I find Bertrand Meyer’s PEGS (Project, Environment, Goals, and Systems) requirements taxonomy much clearer – Hofmeister at al’s organizational factors roughly correspond to Meyer’s Project requirements, technological factors to Environment requirements, and prodct factors System requirements. Meyer’s Goal requirements are incompletely included among organizational and product factors. The authors’ strategies are related to rationales for architectural decisions.
The authors’ four views for software architecture immediately reminds the readers of Phillipe Krutchen’s 1995 4+1 views model for software architectures. Krutchen’s model has been better accepted by software engineers and it is probable safe to say that Krutchen’s remains the dominant model today. Krutchen’s views seem to depend more clearly on different diagrams, while each of Hofmeister’s et al’s four views seems to float rather confusingly on overlapping kinds of diagrams.
Krutchen’s logical view is quite similar to Hofmeister’s et al’s conceptual view -they are both built on class and state diagrams, but the conceptual view also throws in object, component, and sequence diagrams to round out its explanation. Hofmeister at al’s module view (mainly based on package and componen diagrams) seems to straddle aspects of Krutchen’s process and development view – Krutchen’s process view may also depend on sequence, communication and activity diagrams, as well as package and component diagrams. Krutchen’s physical view, which tends to rely on deployment diagrams is roughly equivalent to Hofmeister et al’s execution view which relies not just on deployment diagrams but also on a non-UML standard process diagram -which is particularly suited to high-level real-time process documentation.
Hofmeister, Nord, and Soni present four case studies in software architecting which correspond to real-life Siemens product lines:
- IS2000 a camera probe driven visible light, heat or other electromagnetic radiation imaging systems. This is the most detailed case study provided and it is used to introduce the four views model;In all four case studies the authors choose to present pipelined, layered architectures with important real-time components. Most of the case studies are large or very large projects (at least for 2000), not written in object-oriented programming languages. They use a heavy-weight, non-agile development methodology, and do not take advantage of formal product-line or aspect-oriented engineering techniques.
- Safety Vision, that supports safety-related and safety-critical instrumentation and control systems for nuclear plants;
- Healthy Vision and Central Vision that provide vital signs monitoring;
- Comm Vision to enhance highly-reliable switching nodes for ATM networks.
I would not recommend this book as a textbook for an introductory-level course on software engineering, software product-line engineering or software architecture. It could be an interesting challenge to critically analyze its proposals in the context of real-time, concurrent industrial-scale software systems.
A more positive review, written over ten years ago in 2004 by wiredweird can be found on the Amazon page for this book. A more negative one, written by Oliver Goldman in 2026, can be found at https://ogoldman.github.io/architects.... This review includes the following interesting and/or moot observations:...the book is based on observational study of software architecture at Siemens in the 1990s. If you are also an architect at Siemens and still employed building 1990s-era Siemens products—well, I was going to say this book is for you—but better advice would be to get a new job.
...substantial time is spent on organizing systems into modules, and the reader is told that modules are organized into layers. What they should say is that modules can be organized into layers, assuming a layered architecture […] Assuming that all systems are organized into layers is simply wrong.
...most of the examples feel far removed from multi-CPU, multi-core, cloud-based systems.
Want to Read
July 11, 2011good book...
March 20, 2014
dsddfsd
ghjfgj
hfhfh
ghjfgj
hfhfh
Displaying 1 - 3 of 3 reviews