1 of 1 people found the following review helpful
Good checklist for any software architect,
Verified Purchase(What is this?)
This review is from: 97 Things Every Software Architect Should Know (Paperback)
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 event in any time order.
* Bill de hOra discussion of inevitable tradeoffs using Brewer's conjecture (CAP) as 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 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 do not forget.