Category Archives: Agile & Architecture

This is a delightful little book on the perennial topic of how a software architect should think and behave. While that subject seems to attract shorter books, this one is very concise – the main content is just 66 two-page spreads, with a well-chosen and often thought-provoking illustration on the left, and a couple of paragraphs on the right.  However just as with The Elements of Style, brevity indicates high value: this book provides the prompt, the detail can be elsewhere.

The book should be valuable to many: If you want to be an expert software designer, this book provides an overview of the skills and knowledge you need to develop. If you want to recruit such a person, this provides a set of key indicators and interview prompts. If you are in one of those software development organisations which believes that quality architecture can somehow emerge by magic from the unguided work of undifferentiated coders, this might make you think again.

If you are, or think you are, a software architect, this book should act in the same way as a good sermon: it will remind you of what already know you should be doing, and act as a prompt against which you can measure your own performance and identify areas for improvement. It reminded me that I can sometimes be slow to listen to the views of others, or evidence which may change a design, and slow to engage with new technologies, and I will try to act on those prompts.

This book resolutely promotes the value of modelling in software design. Formal models and analysis have their place, but so do informal models, sketches, and ad-hoc notation. The key point is to externalise ideas so that they can be shared, refined and “tested” in the cheapest and most effective of ways, on paper or a whiteboard. We are reminded that all these are hallmarks of true expert software designers. Code has its place, to prove the solution or explore technicalities, but it is not the design.

The book also promotes the value of richness in these representations. Experts should explore and constantly be aware of alternatives, and model the solution at different levels of abstraction, in terms of both static and dynamic behaviours. Continuous assessment means not only testing, but simulation. If required, the expert should build his or her own tools. While solving simple problems first is a good way to get started, deep, early understanding of the problem space is essential, and experts must understand the whole context and landscape well enough to make and articulate design prioritisations and trade-offs.

I thoroughly recommend this book. It may seem slight, but it delivers a powerful reminder on the process of design, and the necessary, different thought processes to succeed with it.