Applied Software Architecture

Christine Hofmeister, Robert Nord, Dilip Soni
Addison Wesley, 2000

I love the stated goal of this book, namely, "to provide …​ practical guidelines and techniques [to] produce good architecture designs more quickly." Unfortunately, for the most part, it falls short of this goal.

The core issue is that 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.

Ultimately, the narrow nature of those observations limits what this book can accomplish. It’s not that the authors don’t try to generalize what they’ve learned. I think the problem is that they don’t have enough data to work with. For example, 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. The systems under study at Siemens organized their modules into layers. Assuming that all systems are organized into layers is simply wrong.

Interestingly, the book’s guidance is organized around four views—​but not the better-known 4+1 view model. Comparing the book’s model to the 4+1 model:

Table 1. View model comparison
ASA 4+1

code, module

development

execution

process, physical

conceptual

logical

The 4+1 view model had already been published at the time the book was published, so I’m mystified as to why they didn’t use it.

The book is also dated by its heavy emphasis on software designed for purpose-built, single-CPU computers. That doesn’t mean none of its advice applies to more modern hardware. It does mean most of the examples feel far removed from multi-CPU, multi-core, cloud-based systems.

As a final note, the book makes heavy use of a UML. This feels a little forced. In part, that’s because the text contains various disclaimers about how UML didn’t quite align with their use cases, but they adapted it anyway. I assume that effort relates to the book’s inclusion in the Addison Wesley "Object Technology Series". That objected-oriented positioning is perhaps the best way to convey the time and place that permeates this book. Today, software architecture is about much than the organization of classes and objects.



© 2024 by Oliver Goldman