A couple of months ago someone (might have been Stefan Zörner) tweeted about an opportunity to get a book for free. Only condition: One has to write a review. This is the kind of deal I just can't resist. A few weeks later I had the following book on my desk:

"Vorgehensmuster für Softwarearchitektur - kombinierbare Praktiken in Zeiten von Agile and Lean", which roughly translates to
"Patterns in Approaching Softwarearchitectur - combinable practices in the age of agile and lean" by Stefan Toth

When I first glossed over the title, I thought it is just another book about software architectur. One that tries to teach you how to design your systems in order to achieve a particular goal. That is not the case.

It is about a topic which I haven't seen covered in any other book so far: How to solve the none technical challenges when working on the architecture of a system.
Things like: How do you get important architectural decissions communicated. How do you organize time for architectural work in an agile project? How do you get from arbitrary statements like "The system needs to be secure" to something you can actually base decissions on.

I think the topic is great. It is important, it hasn't been covered in other books I know of and the advice in the book is reasonable, plausible and in the case where I already tried the described aproach, basically works as described. This alone is enough for me to recommend this book: If you are responsible for architectural work in a software project, get this book and read it. This of course asumes you can read German. If not, well I hope the book get translated to English, it's worth it.

Sounds like 5 star review? Well, no. While the pure information contained is great value, there are other things to consider: Appearance and Style. The book comes in the standard binding of the German publisher Hanser. It has a thicker cover than a nromal paperback but still some flexibility. The combination makes a easy to handle and durable book. Full points on this category.

The thing I don't like to much about the book is part of the writing style. It is structured in patterns and each pattern is introduced by a dialog between 2 or more developers. I found these dialogs just boring and repetitive because after the dialog the topic gets introduced again in a more formal way. So I think the dialogs are superfluous.

After the problem statement and the description of the proposed solution there comes another section where the pattern is turned around. The section advices you how you can use the pattern to actual make your project fail or at least suffer. When Stefan introduced this in the beginning of the book I though "Cool, fun idea!" But when reading them I actually didn't liked those sections at all for two reasons:

1. The proposed aproaches to make a project fail where pretty uninspired in most cases.
2. I still found my self reading these sections and completely forgetting what I was reading. So I thought "Holy s**t, what kind of nonsense is this!", just to realize what part I was reading half a second later.

So to sum it up: Do get the book and read it. Just don't expect a world changing piece of literature.