I never read books about architecture or architects, and reading this book wasn’t my idea. However, once I commit to something, I see it through. I purchased the book a few months ago, new, for about $66 (Canadian dollars). I’ll come back to the price later. The book itself is relatively small and short, a bit over 300 pages with a well-sized font, ample space between chapters, and the smallest page area I’ve ever seen in a technical book.
I’ve never held an architectural position, and in fact, I have a fairly limited understanding of an architect’s role in the first place. With over a decade as a software engineer, I tend to see architects as people to avoid whenever possible, as they often say “no” to technical or design proposals more than “yes.” Granted, software engineers can be overly eager to make unnecessary changes or introduce new shiny tech that ends up causing more problems or becoming redundant. But to this day, I only approach an architect when all other options are exhausted and never with new ideas or proposals.
“It is often easier to ask for forgiveness than to ask for permission.”
Grace Hopper
Given all of the above, expressing an opinion on this book is challenging, as I have nothing to compare it to. However, I’ll share my thoughts and feelings about it
The Good: The book is easy to read and understand. The author does not waste time stretching out discussions unnecessarily. The list of topics is solid and covers many critical areas of any IT organization. I found a few nuggets that resonated with me, such as automation, standardization, version control, diagrams, and feedback. While I have minor disagreements on automation, I generally align with the author and hope modern IT organizations follow these ideas and recommendations. The book also includes plenty of references to other materials, books and movies.
Ugly bits: While the references to other resources are appreciated, there is an underlying irony: if you’ve read some of the books mentioned, you likely don’t need to read this one at all. Kent Beck, Robert C. Martin and Martin Fowler, for example, provide enough practical knowledge, discussions, and examples that render many subjects covered here self-evident and redundant. Furthermore, while the book covers a broad range of topics, it often lacks depth and detail. It feels like reading an abstract with a bit more substance; the subjects are clear and touched upon, but there’s little practical detail to learn from. It feels like a lot of knowledge but practically little comes to fruition.
The Bad: The author frequently explains concepts through analogies, drawing from non-tech areas. While analogies can be effective, some of these were poorly chosen. Occasionally, the analogies were overly simplistic; at other times, they were unnecessarily complex. In rare cases, the analogy was worse than the technical explanation itself. For instance, the author used forensic/police sketch artists as an analogy for architectural mapping/diagrams. This was frustrating—it felt irrelevant, and I have no interest in, nor do I understand, police work. Another annoyance was the inclusion of URLs for diagrams in a printed book. Why not print them? The chapter on diagrams seemed interesting but ultimately uninspired, as if the authors added just enough content to make it feel important but not enough to fully explore the topic or provide more examples. I found it perplexing that the book relied so heavily on unrelated analogies, considering it isn’t targeted at novices. Surely, any software engineer or architect reading this book would have a baseline understanding of IT. The author could have used this space to provide more detailed discussions and practical examples instead. Lastly, the book’s treatment of hiring and staffing was minimal. While it mentions the importance of interactions across organizational levels, it barely touches on better hiring practices and only in passing. It’s ironic that the author can talk about communicating between the “engine room” and the “penthouse” but neglects to elaborate on Human Resources.
So, what’s the verdict? Let’s go back to the $66 price tag. For that amount, I expected at least 400 full-sized pages of deeper, more practical knowledge. I’m not sure who this book is for. Is it for the ivory tower architect who lost touch with tech a decade or two ago? Or for the new architect who has only heard of Git, pipelines, and containerization in passing at a conference? The book isn’t bad, but I can’t say it’s good either. Would I buy it again? No. Would I recommend it? No. You could gather the same knowledge by locking yourself in a room with YouTube for 10-20 hours and watching IT conference talks by top industry architects. I would give the book a green light for $20, as it is short and has a few valuable nuggets, but not for $66.
In a nutshell:
+: Easy, fast, and short read
+: Covers various relevant IT topics
+/-: Includes many references and broad topic coverage
-: Heavy reliance on analogies, not all effective
-: Lacks depth, details, and practical discussion
=: Don’t waste your money. If you can pick up the book for $20 and are interested in the topic, go for it. Otherwise, spend time on YouTube learning from top industry architects for 10-20 hours, and you’ll likely be better off.
Title: The Software Architect Elevator: Redefining the Architect’s Role in the Digital Enterprise
Author: Gregor Hohpe
Cover:
