Book Review: 97 Things Every Software Architect Should Know
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)