The Architect’s Path (Part 2 - Bookshelf)

Updated: November 17, 2020 Updated: Architecture

Part 1 of this mini-series contemplated an architectural model for a learning path for architects. Now it’s time to fill this model with some content, i.e. reading recommendations, to build an architect bookshelf.

We start from the bottom up, beginning from the design of single components and inching up to a wider scope. I present a “shelf” for each layer in my model. This means that the model has a linear dimension (axes kinda tend to be), but of course you are free to plot your own path across these layers.

Let me highlight that the books I mention here aren’t any sort of a “top 10” list, which would relegate other books to lower positions. Rather, it is a sampling based on my experience and is meant to depict one plausible path for architects without precluding many others from co-existing.

Shelf 1: Single Components

When designing a single software component, architects should focus on good coding and design practices. Following the horizontal axis from left to right (from specific to abstract), I find the following books to be useful for this layer (with overlay links - thanks, Jekyll!):

• Clean Code by “Uncle” Bob Martin. Good software starts with good code, and good code is clean. Here we start with the basics of naming, functions that do one thing well, and formatting.
• Refactoring by Martin Fowler. Good software doesn’t just happen - it evolves, gains entropy, and is then restructured. The book’s subtitle reveals that this is a book about design.
• Design Patterns by Gamma, Helm, Johnson, Vlissides. Going ever so slightly more abstract, design patterns help us make balanced decisions on the design of our code. This title must be close to 1/2 million copies sold by now.
• Pattern-oriented Software Architecture by Buschmann et al. A close sibling to “GoF”, POSA 1 takes a slightly broader view, including some communication patterns. It’s the start of a whole series on software architecture patterns.

Strictly speaking, design patterns are concerned with multiple “components” if you consider a class a component. I’ll go with a more physical definition of “component” (aka “service”) so I am happy to group OO patterns into “single component”.

Shelf 2: Connected Components

Interesting software rarely lives in isolation, so we should look at how work is broken down into pieces and how the pieces are interconnected. The following books provide architectural guidance on this layer:

• Building Microservices (a 2nd Edition is in the works) by Sam Newman is really a book about architectural trade-offs and considerations in distributed system design rather than a pitch for one specific solution. That’s why it’s a great book for architects. It’s also very accessible.
• Fundamentals of Software Architecture by Neal and Mark, although also covering soft skills, dedicates the majority of the book to modularity, component-based thinking, and architectural styles. Just what an architect needs to wire things together in the right way.
• Enterprise Integration Patterns is still relevant 17 years after publication (OK, minus the funny MSMQ examples and Java 1.4) for anyone trying to connect systems without coupling them too tightly. Several modern examples are available on-line.
• Pattern-oriented Software Architecture 4—inching towards conceptual, this tome from the same “POSA” series is a tougher read, but is one of the most comprehensive references for distributed system design.

I would love to have included a book on API design in this list as the interfaces are a critical element of wiring pieces together. Most books I have read are quite specific to a single protocol or style, though (like REST). I’d prefer a title that goes into trade-offs and design decisions more so than recipes or best practices. I’ll keep looking.

Shelf 3: Entire Systems

Now it’s time to zoom out further and look at the system as a whole, the forest and not just the trees, so to speak. This is where we find several of the “classic” software architecture titles:

• Just Enough Software Architecture by George Fairbanks is a very approachable, yet quite comprehensive title that’ll make a good addition to any architect’s bookshelf.

• Software Systems Architecture by Nick and Eóin covers a similar scope to George with a slightly stronger emphasis on viewpoints and perspectives. Written by hands-on architects, it shares pearls of wisdom on most every page. The only suggestion for improvement would be to condense the content down a tiny bit—almost 700 pages require a lot of discipline and patience.

• Thinking in Systems—when looking at system design and behavior from a conceptual point of view, all roads lead to system thinking and complex system theory. It’s hard to pick out a single book from this field, so I recommend Donella Meadows’ book as a gateway into this topic space.

• The Model Thinker—this one should perhaps be in parenthesis. I firmly believe that model-based thinking is critical for architects and very much enjoyed Prof Page’s Coursera course. However, most of the models are mathematical, requiring some translation in your head to apply them to software systems engineering. Still, I am convinced the book will leave you with a novel attitude to systems design and decision making, so I am keeping it on the list.

There are quite a few more more books that I’d like to include in this “shelf” but I have not been able to read (or buy) all of them yet. For example, System Architecture is on my list but it’s $130+, so it’s kinda difficult to include it in a recommended reading list.

Shelf 4: Context

Experienced architects know well that the story doesn’t end with being able to design entire systems. Architecture happens in context (we deal with the “non-requirements”), so understanding that context is an important skill for an architect. In fact, missing the context renders all other elements irrelevant. So, there’s one more shelf on the top:

• Technology Strategy Patterns by Eben Hewitt is a nice catalog of all the stuff that appears in consultants’ fancy slide decks that you as an architect afterwards have to deal with. So, it behooves you to understand what’s going on there.
• The Phoenix Project and it’s buddy The Unicorn Project by Gene Kim and his tribe are standard reading to better understand the interface between business and IT and what can all go wrong there.
• The Software Architect Elevator—although feeling slightly sheepish for including a second book of mine, this one deserves a spot. It gives architects a broader view of their role and impact in an organization beyond technology. It’s not very conceptual, but I am placing it on the right out of modesty.

Many more books would belong on this shelf. Rather than pick a fourth title, I’d like to include a pointer to other relevant domains such as enterprise architecture (good books about which are surprisingly rare), business architecture (good books about which are rare to the point of almost non-existent). I am inserting a pointer here to a previous blog post on the penthouse architect bookshelf (and what more appropriate animal to choose than a Maus?).

The First Derivative

As if the banner image wanted to give a hint, we find that our model is missing an important dimension: time. As hinted in Part 1, architects live in the first derivative—they deal with rate of change as a major input into their design. So in an Interstellar-esque move (see the banner image) we have to add time to our bookshelf. I have no idea what that looks like (I’m no Christopher Nolan), so I’ll just make a little stack of books on the side:

• Continuous Delivery—software comes into being because it is being delivered. If you are concerned with rate of change, this is something you’d want to be doing continuously. This book just celebrated its 10th anniversary and is as relevant as ever.
• Accelerate—acceleration is the second derivative of position (speed being the first), so if you want to move faster you need to accelerate. Sometimes, you need to jerk the system a bit, which in fact the proper term for the third derivative.
• Building Evolutionary Architectures describes how to use fitness functions to guide architectural change over time. I thought the authors could have gotten a bit more our of this topic - perhaps we’ll see a second edition.

The Whole Shelf

So, here’s a cut at the whole architect’s book shelf based on our architectural model of a learning path:

An Architect’s Real Bookshelf

What does a real architect’s bookshelf look like? Here is a small sample—two of my more organized shelves (click to enlarge):

You can see almost all the titles I mentioned in this shelf, including the whole POSA series on the bottom right and a section on Software Architecture (with a good SEI representation) next to it. Above, a section of Springer Books, DevOps / Accelerate, and Systems Thinking. Then we move towards Object Design and Cloud / Web Services / Events, before arriving at software management classics like the Mythical Man Month, and finally broader books like Thinking Fast and Slow and Antifragile (ignoring the amazing Japanese train schedule books). Curiously, my books are almost in the order we chose for our learning path.

What’s Missing?

There surely is a lot missing from my bookshelf. I need to find a place for Simon Brown’s books on Software Architecture for Developers, for example. And Mike Nygard’s Release It!, which touches on many important operational aspects.

Also, you notice that books targeting specific products or associated certifications are absent. Those certifications also offer a path, but that’s really a parallel universe. I often refer to them as the “driver’s license” whereas I am looking to help architects become successful racers. Having a license doesn’t hurt, but you won’t win the race with it.

I think that quite a few books are also still missing from the book stores. Aside from Enterprise Integration Patterns 2, the books I am missing most are those that are conceptual in nature but have the same depth of discussion as the hands-on programming titles.

It seems that we have to choose between detail at a low level and fluff at a high level—I don’t think that’s right. Cloud Strategy is my initial step at filling this gap and we should see more books along these lines. Keep a bit of spare room on your bookshelf!

Make More Impact as an Architect

The Software Architect Elevator helps architects and IT professionals to take their role to the next level. By sharing the real-life journey of a chief architect, it shows how to influence organizations at the intersection of business and technology. Buy it on Amazon US, Amazon UK, Amazon Europe