Review

Srinath Perera
Addison Wesley, 2024

Software is everywhere. It’s in the "obvious" places, such as the apps on our phones and the services we use in the cloud. It’s also in cars, TVs, airplanes, ovens, doorbells, robots—​you name it. Yet many practitioners, when writing about software, struggle to see beyond the boundaries of their experience. For them, building software is implicitly scoped to the kind of software they build.

That is the first of several limitations in Software Architecture and Decision-Making. The book claims to address software architecture in some broad sense, but it does not. As the cover illustration suggests, this book is more narrowly scoped to the architecture of cloud services. Ultimately it has an even narrower scope, being primarily focused on enterprise services of the type a company might create to run its own business.

There’s nothing intrinsically wrong with writing a book about building in-house cloud services. It is certainly a popular topic for software architecture books, and there are many people employed doing such work. The problem is that much of the advice in the book applies only to such scenarios. For example, one oft-repeated bit of advice in the book is that "we will rewrite the system eventually." If one takes that as a given, then many decisions need only be made for the version of the system being written right now. Other things can wait.

Many readers will be skeptical, and rightly so, that such rewrites will happen. It may be more true in enterprise systems than in commercial systems. I have not seen data on this point, but I find it a credible hypothesis. However, the notion that commercial systems will be rewritten seems demonstrably false. Successful commercial systems evolve, but they are not rewritten. To do so would be too expensive, too risky, and too impractical.

Were that the only limitation of this book, it might still be a practical guide for architects of enterprise cloud services. However, this book contains some guidance that I can only describe as harmful. For example, it recommends storing user profiles for marketing and sales purposes in the system’s user authentication system. That is a terrible idea, violating basic architectural and security principles.

Were the book otherwise well-written, a debate on such matters might be interesting. Exposure to other points of view and questioning assumptions can be a worthwhile exercise. But this is not a well-written book. Words are abused; "leadership" and "principles" are used regularly to refer to things which are neither. Sentences contain what are, if not grammatical errors, certainly confusing constructs. I have no insight into the development of this book, but it reads as if the author’s raw draft has been published without the benefit of editing or proof-reading.

Software architecture and decision-making are two of my favorite topics. Unfortunately, you won’t find this book informative on either count.