Fundamentals of Software Architecture

I picked up Fundamentals of software architecture last week. Overall the book is good as a starting point.

  • It’ll help introduce and define the basic concepts.
  • try to quantify them with simple equations.
  • describe some of the famous ways software systems are organized
  • and there is a small part of the book at the end that talks about soft skill needed for an architect.

Sometimes during reading it I had to scan the paragraphs to see if there is something important in it. As sometimes there is a tendency to expand on trivial points and even provide examples and reference tables to it.

One section in the soft skill the authors were talking about “How much control the architect should exert on a team”. then they named two sides of the behavior:

  • Armchair architect: doesn’t care too much about the details
  • Control Freak architect: controls every bit of the system and how it’s implemented

And the goal is to be in the middle of these two examples and swing back and forth depending on the team size and knowledge…etc

But they went too far in the description and examples even added some stock photos for an angry man pointing to you and another lazy stock photo guy on a chair. then went to quantify teams need for control in a table and how to calculate some rating that then you can use it to decide how much control you can put on the team.

Back link to O’Reilly books

The book is full of mentions to other books in the industry mainly O’Reilly published books. It feels like when you visit a blog post now and it’s full of links to other posts on the same website just for the sake of SEO. very view other examples are mentions like “The Mythical Man-Month”.

Written by two authors and feels like so

The books is written by two authors and feels exactly like that. Some parts are humble and shows skepticism. like mentioning that it depends on the situation or the requirements. Other parts especially the ones the mentions team activities are very assertive and sounds like stating facts.

Black and white print wasn’t considered

In some cases the books was describing diagrams with different colors. But the book is printed in black and white. So it seems the authors didn’t consider this fact while writing this part of the book?


The book is good. It’s one of these books that are documenting what the rest of the industry is doing and it’s important to have such books to have a well-documented history of our industry. But I can’t stress on this point enough.

Here is how I see it:

  • People got together and built software
  • The software is getting bigger
  • The have to come up with rules and guidelines to enforce consistency and other benefits
  • The end up in long transitions from current state to another better and consistent state
  • Some patterns emerge between different people doing that
  • We notice that and write books about it like this one.

The problem when the flow goes the other way around:

  • Developers read the book as if it’s a holy scripture
  • Developers like one of the organizations in the book
  • Developers want to cast the current system they work on to this specific organization/pattern
  • We end up in a holy war between different people with different opinions and preferences

So It’s important to look at this kind of books with skepticism and use it for what it’s written for:

  • Documenting what other are doing in an organized way
  • Getting some lessons learned from other situations

And we have to know that every system is very different. the organization structure is different and the software goals and required characteristics are different. So each of these proposed solutions are not a unit by itself. but can be broken down, mixed and combined with other patterns to build the goal system.