97 Principles for Software Architects

I just concluded 97 Principles for Software Architects – Axioms for Practitioners (Multiple authors, 2020), and it was a great journey.

To start with, it is not usual to have such a large collection of chapters put together by so many different practitioners. At least it is unusual for me to read or listen to something like that. But, in this case, I must say it works.

And it does so because of the quality of the voices put together. And the cadence of the change of topics and perspectives along the way. Although I know little to nothing about the experienced software architects behind each chapter, I understood right-away they are indeed experts in their field. In short, due to the sheer amount of high quality and relevant insights they present.

Being a great software architect is all about trade-offs. It is all about people, technology, business, and a whole bunch of other things. It is simply too overreaching to simplify it any way. There are always multiple layers of meaning and considerations behind the skills required of a good architect.

That’s again why 97 Principles makes for such a great companion. It brings a large number of relevant discussions, distilled from multiple and diverse real-life experiences. If you’re a software architect, or an aspiring one, you will not be disappointed.

Team Topologies

I concluded recently Team Topologies – Organizing Business and Technology Teams for Fast Flow (Matthew Skelton, Manuel Pais, 2019, 240 pages), and I think this is an impressive book for those thinking about how to organize teams in a software company.

I’ve actually started noticing this book as a reference in several other good books about technology, products and teams that I read in the last couple of years. So, I knew this would be good. But it actually surpassed my expectations.

What is so interesting here is that this book builds on top of solid traditions of Agile, Lean, DevOps, etc., and focuses on the problem of organizing teams. To start with, teams are the unit we all should have adopted for getting complex work done. That’s because of the sheer brain bandwidth required to deal with hard problems or complex systems.

Then, one of the ideas I like the most here is that stream-aligned teams are key to keeping the flow from the tech side to the final users. Stream-aligned just means aligned with value streams in the company, which ties it back perfectly with the overall business goal in the organization. The book brings lots of ideas about how to organize such teams.

In addition, complex sub-system teams, platform teams and enabling teams are the remaining team types that all other teams can be mapped to. With only 4 team types, and some pattern of expectation on how these teams will work and interact with others, the whole structure can be much easier to understand and implement.

If those ideas sound interesting, this book is definitely a great reading for you too.