Book Review: 97 things every Software Architect should know

You can't judge a book by its cover but you can certainly ask questions about its title. Why '97 things every Software Architect should know'? Why not 98, 99 or even 100? Well the word on infoq is that they wanted a number near 100 so that there would be enough material for a reasonably sized book. Fair enough so... The book contains 97 articles published by a range of software professional expressing their views on various aspects of software architecture. Many of the articles are not very technical in nature and there are - perhaps - a lot of similarities between this book and '12 Essential Skills for Software Architects' where author Dave Hendricksen focusses on non-technical skills essential to be a succseful architect. Other articles probably aren't just things an Architect should know but really things anyone working in Software Engineering could benefit from knowing and thinking about. I even include Project Managers in that!

That said, there are some really enjoyable bits and pieces. My favourite parts:

• Keith Braithwaite's reminding of the architect's need to quantify things. Characteristics such as average response time should be not be phrased using terms such as 'good' or 'satifactory' but quantified as something like: 'between 750ms and 1,250ms'
• Craig Russell's points about including the human interaction time in any performance analysis. The system may respond very fast to API calls, but the if the UI is counter-intuitive, it means the user will spend a longer time try to get his result.
• Michael Nygard advice for engineering the 'white spaces'. Don't just have arrows between components specifying the communication protocol, describe the performance expectation of interaction e.g. 100 requests per second, response time 250ms 99% of time. Describe how the system will handle overload, bad response times, unavailability etc.
• Mark Richards classification of architectural patterns:
• Enterprise Architecture Patterns: EDA, SOA, ROA, Pipeline architecture
• Application Architecture: Session Facade, Transfer Object
• Integration Patterns: File sharing, RPC, Messaging
• Design Patterns: GoF

• Gregor Hohpe arguments about the 'predictive call-stack architecture' becoming a thing of the past.
  In massive distributed systems, it's not so easy to define the order things happen in. Architectures now have to be able to respond to events in any time order.
• Bill de hOra discussion of inevitable tradeoffs using Brewer's conjecture (CAP) as an example.
• Dave Anderson's arguments for the inevitabitly of legacy and preparing your system for maintenance.

So plenty of good advise in a short book that never gets too technical. The role of the architect is not just to be capable of understanding complicated problems but to stand back and look at the big picture, checking for gaps and to ensure the right actions are taken to ensure project success. This means it's not really just about things a software architect should know, but about things a software architect should ensure they never forget.