Beautiful Architecture is a kind of follow-up of Beautiful Code, which I reviewed some time ago. Far smaller, the book is aimed at architecture, although Beautiful Code also presented some aspect of architecture.
The question I’ve asked myself whether or not it is as good as its predecessor.

Content and opinions

The editor split the different architecture topics in 5 parts. The first is very general, and short. The main topic is why you should have a good architecture, with some real experience with good and bad architectures. It’s a necessary introduction, even if the content is to be expected.

The second part left me with mixed feelings. If you’re used to architectural readings, you won’t learn much, in my opinion. OK, it’s a book on software architecture, but actual architectures are expected, and some displayed architectures (like web services) are obvious, although Facebook’s chapter is interesting in that matter.

The third part is dedicated to hardware, emulation, virtualization or real one. This was really interesting, with a lot of details on known projects (Xen) or lesser-known ones (Guardian, which I didn’t hear about until the book, but which was really interesting in its philosophy). I had less interest in both Java projects, as it’s not something I deal with on a regular basis, but the approach was enjoyable.

After the hardware, two chapters are dedicated to two well-known projects with really different teams, Emacs and KDE. KDE’s chapter is almost more about the team and how the architecture emerged from team’s discussions than architecture itself, and I think that another message behind this part is to learn to communicate inside the developer team.

Finally the conclusion starts with a discussion on object-oriented languages (the kind that is mainly used) versus functional ones, by a reference in that field, Bertrand Meyer. One has to be focused to fully understand Meyer’s message. For his demonstration, he uses a real object-oriented language, Eiffel, and not one of the usual not-fully object-oriented languages like C++ or Java. So some concepts may be missing to you. And the last chapter is about overdoing an architecture and finishing with a half-baked software with examples from the buildings architecture where some famous architects overdid their work and losing sight of the buyer’s needs. Like every book on architecture or software conception, it is best to explicitely state that too much is the enemy of a good program.

Conclusion

Less surprising than its predecessor, shorter and with less magnificence, this book is sometimes more boring. From a cultural point of view, it’s a good one, with examples for very distinct fields. Some chapters are too obvious if one is familiar with the field, and this spoils a little bit the pleasure of reading.