Review

Juval Löwy
Addison-Wesley, 2020

As it says in the subtitle, this is a book about "a method for system and project design." The first half is about designing those systems; the second half, about running the projects that build them.

Löwy is perhaps too certain of himself when he elects to call his method The Method, his claiming that this method works for designing all systems. In doing so, he makes an error of scope that is common to many books on software architecture. Namely, he forgets to specify his scope: what kind of systems is he writing about?

There are many kinds of software systems. Some systems control robots. Others control cars, rockets, or dishwashers. Some are videos games, others are operating systems, and yet others process real-time sensor data.

The systems to which Löwy’s method applies generally fall under the label of "line of business" systems. These are often "internal" systems—​as is the primary example in the book—​automating a company’s operations. They may have external-facing aspects, such as a website. But they are not operating systems or rocket control systems. They do not run dishwashers.

I know of few architects who’ve worked on many different kinds of software systems. Architects, it seems, tend to specialize. For example, early in my career I worked on a video game (it never shipped) but, truthfully, I didn’t much enjoy building that kind of system. Instead my career arc bent towards web platforms and cloud computing. While it is sometimes tempting to generalize, I try to mind the limits of my experience.

Along the way, I have spent a few years on line-of-business applications. Based on my experience, I have no doubt that The Method works for the intended kind of application. I might describe it as a method for designing line-of-business systems according to a specific architectural style, that style using layers, orgnized into managers and engines, and so on. It’s an appropriate style for line-of-business applications. It’s useful to have a method for developing architectures in this style. But Löwy goes too far in claiming it’s broad applicability.

That’s the "software architecture" half of the book. In the second half, Löwy describes the project management aspect of The Method. Now, Löwy holds that project management is part of the architect’s role, and I fundamentally disagree. I suspect most project managers share my point of view. (Conversely, I would not expect a book on project management to describe software architecture.) Here I think Löwy has confused what he does—​which is to fulfill two roles—​with the need to claim there’s only one role. And as I’m not a project manager, I cannot claim to be qualified to evaluate that half of the book. I will readily believe it’s a solid project management method for line-of-business application development.

That said, even if you are not writing a line-of-business application, Chapter 2 is worth a read. Titled simply Decomposition, it’s a great exploration of why functional decomposition tends to produce poor outcomes. Specifically, functional decomposition tends to lead to systems composed of many tightly-coupled elements because the system’s behavior—​what it actually does—​emerges only from the combination of many discrete elements working together.

Löwy explains that creating loosely-coupled decompositions actually requires decomposition based on "volatility." I’m putting "volatility" in quotation marks here because it’s an unconventional use of the term in software. Nonetheless, its meaning is intuitive and the approach he champions is straightforward:

Which is really just another way of stating that well-architected systems are created from highly-cohesive, loosely-coupled building-blocks, ready to be combined in different ways and hiding their implementation details. That’s a lesson that I believe applies to every software system, and Löwy writes one of the better explanations of why that’s true.