This is a controversial book. They claim to be an “Engineering Approach,” but the text is full of opinions and personal tips based on the author’s experience, yet I liked the reading and how the authors structured it. But if you don’t like opinions and prefer a more scientific approach, this is probably not a book for you.

Nevertheless, I think the reading is worth it for architects or aspiring architects looking for many topics worth studying, though the book won’t go deep into any of them.

One of my favorite things about this book is their questions at the end of each chapter, which made me think about what I read. It also got me challenging myself to answer all of them.

This post did not follow the same order of subjects as the book. It was created from the notes I took while reading. Then I try to classify the book’s topics into different chapters here. Feel free to jump around the topics you are interested in the most.

Software Architects responsibilities

The book defines (based on the authors’ opinions) some responsibilities for the software architects. I agree with most of them, and a few catch my attention especially. For example, they mention “performance” as an architect’s responsibility, which I agree with, and I also think developer experience(not cited in the book) is an architect’s responsibility. Why?

1. If the design is perfect but prohibitively slow in its implementation and performance is vital for the application, the design must change.
2. If the dev environment becomes too complex or challenging to learn because the design of the components and its boundaries are too complicated, it needs to change, and the architect has failed.

Pragmatic Software Architecture

The authors sometimes show a pragmatic software architecture approach. For example, they advocate that architects should not “Try to get to the best possible architecture, but the least bad one easy to change?”. The core point here is “easy to change,” and this, in my opinion, is the number one factor of a good design. Good design is easy to change and extend, just like good code, and that is why I have the “Secret before commit message” asking me that question all the time I do a commit.

The book defines architect characteristics as not related to the domain. Yet, it defends that the domain pays the bills, so architects have to pay attention to the domain carefully.

The phrase “Scalability is a problem of parts of the system, maybe not for all systems” made me rethink some past situations, read the phrase and rethink how you think scalability.

They define a straightforward to determine if an aspect is architectural or domain concern defining a simple question, “Does it require domain knowledge to build?” If yes, then it is a domain concern.

Architects should not worry about micromanagement. Otherwise, they will prevent new leaders from coming up.

How do we train new architects?

The book got me thinking again on an open question, “How do we train new architects” this topic deserves a post on itself, so I will not talk too much about it here.

The short and straightforward answer I can give to that question is: We need to let they(the aspiring architects) design systems and implement them; bring them to reality, and see the problems their design created, refine the design, and repeat. Soon I will have a dedicated post to this subject, so follow me on Twitter if you want to get notified when it is out.

Aspects of Software Architecture

They also define several aspects of software architecture, including elasticity and difference from scalability, customizability, performance, and performance budget.

I liked their idea of validating non-functional aspects of an application with a “Fitness Function”. In practice it isn’t very easy to implement such things, but few would agree they are not a great solution.

In my own words, a Fitness Function is a piece of code or software that can validate one non-functional requirement. For example, a non-functional spec requires 100% of the external APIs to be documented within an open API. So a potential Fitness Function could be a script that analyzes the code finds the exposed APIs, and validate if they are present in the open API json or YAML files, and in case some are not, it fails the build.

Creating such “Fitness Functions” is not easy given the complexity of non-functional requirements sometimes. For example, some performance requirements may require that some subset of operations cannot take more than 50ms; on paper, that is easy, and it is trivial to monitor and alert in production if it gets out up spec. Now in dev, to block a PR when it gets out of spec is a bit more complicated; since it may require a prod size database and a good amount of concurrency to ensure the results are valid. That is complex to implement, though it is possible and probably worth it in many cases.

The book mentions some “Fitness Functions” may leverage rages of allowed values. It can help Fitness Functions for aspects like performance to make them easy to implement and deterministic success or failure. The vital point here is to make the build not deterministic. It is an enormous problem if the team does not trust the test results.

Another challenging example of non-functional requirements is failure tolerance. And I don’t know how to do it so fast it would fit in build time. Still, there are reasonable solutions for running systems like “Chaos Monkey” that can induce intentional fails into your application. Still, they are more used in running environments than to block PRs or deployments.

Do we need architect governance?

The book brings up the importance of architect governance, with a group of architects taking the hard decision on big organizations. I am still not sure if I agree with this idea; in my experience, having one person responsible for making the last decision works better. We may have an architectural consul, but one lead architect must decide on the hard decisions needed.

One particular expression caught my attention in the book, “DDD has great influence in the modern Software architecture” the book by Eric Evans has unquestionably influenced my architectural design. It was the first book my mentors recommended me to read to become an architect (back in 2010) and other ~20 books.

Topics neglected by the developers when writing code.

In the “Foundations” chapter, they define a subset of topics that may be neglected by the developer when writing software, for example:

1. Network bandwidth is infinite and reliable.
2. Latency is 0ms.
3. And I would add, free.

Unfortunately, none of those are true, and when coding/designing, we must account for that.

Architectural Styles

The authors define several aspects to evaluate architectural styles. I liked some of them more than others, for example: Is it a domain or technical partition? Is meaning the way to define boundaries among components are technical or domain-based?

They evaluated several styles following the same checklist and expressed their opinions about them. Of course, some well-known architectural styles like Microservices are way better explored in other books, but they give a good context, the same with less hyped styles like, for example, the MicroKernel.

The authors dedicate about the same space to present each style, and I think it may be worth reading the ones you know least, like MicroKernel and Space-based, if that is the case.

In this post, I won’t get into those aspects. It would be best to read the book to get the details of each architectural style. Keep in mind that the authors express their point of view about each of them, and you should probably read it and cross with other references and create your own opinion and experience about the styles.

Less Controversial topics of the book

The less controversial part of the book starts after the architectural styles, where the authors talk about subjects like, for example, ADRs, a well-known yet not fully incorporated tool to help document the architectural decision. Moreover, the importance of risk management, assessment, and presentation skills for software architects.

The Architect archetype chapter is a fun and informative chapter. I have seen every one of the archetypes they described in the book at some point in my career. The “Armchair architect” is the most annoying one to see in real life, and it is impressive how they, most of the time, have a strong belief that they are at the top of the world with their three-box meaningless diagrams. But, of course, you want to be an Effective architect.

Conclusion

These books took much more time to review than I anticipated. Maybe you should not read it back to back as I did. Perhaps you do a quick pass over the topics, choose the ones you liked, and read them only.

Still, it is worth it for young engineers who want to become architects. It can give you a backlog of topics to research and try. Just keep in mind the book is opinionated, and you need to complement any knowledge you get from it with other references.

My Open questions after reading the book

Is It possible to have a single architect in big projects?

Software architecture has many aspects that it is too much for a single person to manage all for complex and big projects.

In the company I work for, we have multiple architects assigned to a single product to take care of different aspects of the application. However, we have a leader who will decide if a conflict ever happens. We have at least three architects in the same project:

1. One front-end performance and optimizations.
2. One for platform scalability and performance,
3. The Lead architect.

Additionally, we train new architects to take care of other teams who need guidance in tests, quality, and developers’ productivity.

In one of my past experiences, I was the Lead architect building the company’s framework and all the dev tools needed to support a +100 devs company to migrate a legacy ERP/CRM system to web/mobile.

After more than five teams fully operating and using the framework and the tools we built, I felt the need to have more architects to help me with different problems. So I trained and promoted a few of my senior engineers to become architects. It yielded great results, and they could take a huge chunk off my shoulders, and I could see projects getting to levels that surprised me a lot.

How do we manage this in big companies???

I think architectural committees for a project may not work.

Should we always have a more general architect taking care of the overall aspects and other architects taking care of smaller parts??

Or just let independent architectural patterns appear and let the best ones win? I will talk about it with others and see how this is done in their companies.

Where to find it

Amazon

Reviewers

@pedrokohler