Thinking Architecturally (book review)

Today I want to share a short ebook by software architect and author Nate Schutta. Thinking Architecturally is available for free on the VMWare website (author’s employer at the time of writing).

Thinking Architecturally is a perfect read for mid-level & senior developers who want to focus on the right things in our noisy industry. Unlike many other architecture books, it stays away from technical jargon and philosophical abstractions. It’s practical and easy to read, even if you know nothing about software architecture. Each chapter ends with exercises (katas) that welcome you to think architecturally.

If you trust my taste, go ahead and download the book. If you want a sneak peek, below you can find a few of my favourite quotes.

Technology Changes

Technology will change and frankly that is what attracts many people to this industry. Learning new things keeps things fresh! But more than a few of us are guilty of practicing resume-driven design, of choosing a technology not for fitness to purpose, but to be able to add it to our CV.

In the first chapter, Nate shows that technology repeats itself, and we can avoid unnecessary mistakes by learning from the past.

Thinking Strategically

Hope is not a strategy. As a senior technologist, you need to keep up with changes in your industry.

The author talks about information hygiene, a T-shaped skillset as a better replacement for “Full-Stack”, Tech Radar and other strategic approaches to stay current in our industry. Most of his recommendations are not new. They are available for us now and for free. The book does a great job promoting good old practices like local meetups and book clubs.

Evaluating and Choosing Technologies

Risks cannot be eliminated completely, but they can be managed. Consider each risk [of a new technology] and how you can mitigate it.

If you have ever wondered how to choose between multiple technologies or tools, chapters 3 & 4 of Thinking Architecturally are the answer. I usually follow my own “How to investigate technical solutions” to evaluate new tools, but I have to admit that Nate’s version is much more thorough.

Funny enough, the book includes an example of an evaluation of Angular and React (at the time when Angular was slightly more popular), and React wins it.

Introducing Technologies

As a senior technologist, your ability to communicate will dictate outcomes. Don’t be afraid to take that internal workshop on presentations.

I noticed that most architects compare their work with marketing and sales. It’s not something we usually learn as software engineers. Throughout the book, Thinking Architecturally emphasises the importance of networking, (over)communication, and learning initiatives such as meetups, book clubs and hackathons.

These “soft” activities are strategic tools for architects to cultivate the right architectural principles across the organisation.

Maintaining Technologies (“ilities”)

I met Nate, the author of Thinking Architecturally, at GSAS Barcelona, where he ran a workshop with the same title. At the workshop, we worked in groups on a random Architectural Kata (another great resource available for free). This is when I learned about “ilities” - software quality attributes that often end with “ility” (Scalability, Usability, Maintainability, etc).

If you’ve been recently preparing for the systems design interview, you may recognise “nonfunctional requirements”.

Below is what Nate says (and I very much agree):

For much of my career, I referred to the ilities as the nonfunctional requirements. And that term is still appropriate! However, a colleague convinced me there was a better phrase. We were walking through the architecturally significant requirements on an application when he made a great point. Most customers hear the “nonfunctional” part of the term and decide immediately that they only want functional requirements, stopping the conversation. But we have to convince them of the importance of something they can’t readily see. Framing the quality goals as something nonfunctional implies they aren’t required for the system to work.

Chapter 6 of the book gives clear guidance on how to identify, rank and measure quality attributes. It helped me to structure my intuitive approach to day-to-day software design. It helped me to think architecturally!

To summarise

Thinking Architecturally is my first recommendation for software engineers looking for ways to stay current and grow in the rapidly changing tech industry. This short ebook has already affected how I mentor senior developers on ADPList and how I approach my own learning.

If you are interested in software architecture topic, you may also like my article The road to Software Architecture (frontend edition).