There are many books out there about software architecture and design. Not many combine this discipline with Agile Software Development. There are also many Agile books out there. Still, these books merely touch this aspect by stating general principles. The result is that many Agile teams are still struggling with questions related to architecture. So, I was glad that Simon Brown wrote a book specifically targeted for developers. This post is my review. It will hopefully encourage you to buy the book at LeanPub.
Conclusion, as you may already guessed it, the book is good, useful for a number of purposes, but one in particular: Sketching and documenting architecture and design. The book will give you as a developer a large number of tips and tricks to make effective sketches and effective light-weight documentation. Does this book cover everything in breadth a developer needs to know about software architecture? No, definitely not. It touches a lot of subjects like BUFD, architect’s role, definitions, different types of architectures, collaboration practices. None of them is described as well as the one mentioned above.
If you think: “Architectural documentation and Agile, that does not sound good!?” Don’t worry. The way Simon presents this, it does not contradict Agile principles and Scrum in any way. It merely gives you many possible options in dealing with challenges related to software architecture Agile teams already definitely have.
The book begins with definition of architecture. The message is that there are many definitions, but can be divided in verbs and nouns driven definitions. Both are valid. In the well known confusion of different types of architectures, Simon defines his own preference: application, system, software, enterprise. The new thing here for me is how Simon stacks these. Application is the smallest perspective, system might contain multiple applications and software architecture is the combination of the previous two. While these types are well interconnected, enterprise architecture is placed somewhat outside this very much technological perspective. I like that Simon simplify things and does not put much relevance to this division in types because exact difference is not important and brings a lot of unnecessary confusion. I didn’t really find argumentation why this division is relevant or better than any other.
After explaining importance of managing risks, software architecture role is explained as something that can be fulfilled by a person or a team. How this role could be fulfilled by a team is not really explained, which further emphasises my negative opinion about having a role in the first place. At the end, I don’t share opinion that teams need an architect, architecture role, master builder, architecture owner, or anything similar. Teams need knowledge and responsibility for taking care of architectural aspects. Having a role, only confuses things, and covers up the real problems many Agile teams have as mentioned by Simon. I’m afraid that explanation by Simon will further encourage many architects to protect their kingdom instead of help teams take care of this extremely important discipline.
Simon’s further explanation is about what kind of things an architect usually does: e.g. building prototypes, proof of concepts, perform code reviews. Also importance of being generalising specialist. My opinion: these are all very important things that developers should do occasionally. All developers don’t need to know and do everything, but because architecture is such a broad discipline it is very natural to spread this over multiple developers. This happens automatically driven by knowledge and experience of each team member.
Still, I was glad with importance of having “hands-on software architect”. Simon explains very extensively what this exactly means. I suspect that by applying these things, the difference between architect and developer will blur significantly.
Designing, visualising and documenting software
These parts of the book are the most useful ones in my opinion. Simon covers the most important aspects in dealing with software architecture. It starts with architectural drivers: functional reqs, quality attributes, constraints and principles. These are well explained with a lots of practical advise. Teams can use this as a checklist. I like his opinion on term “best practices”.
Simon gives a well-balanced and practical advise about usage of design tools and UML. A number of often used views in approaching architecture from different perspectives is explained. A number of useful advises are given about how to keep things simple and importance of simplicity.
Agile teams love using post-its, whiteboards and flip-charts. A big chunk of book explains how to use these effectively in communicating architecture and design. Also, many pitfalls are explained.
Chapter about documenting seems an extension of the previous two. Simon strikes a nice balance of lightweight documentation. Each type of essential information every software architecture has is explained by blocks containing intent, structure, motivation, audience and wether it is required. If it isn’t clear what I mean, go buy the book. It is very useful stuff. 🙂
The last part is about number of things named “software architecture in the development lifecycle”. It should help developers in dealing with questions of BUFD, significant decisions. The explanation is useful, but lacks argumentation. It seems based on personal experience of Simon, which is still definitely useful.
In a bit unexpected place in the book you will find very practical advise in dealing with risks. Risk-storming is a really nice practice.
Only the very last part of the book touches aspects of incorporating architecture as a discipline in teams. I’ve expected a bit more because of this huge problem that Agile teams don’t know well enough how to organise architecture process.