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.
Thank you for the info. It sounds pretty user friendly. I guess I’ll pick one up for fun. thank u.
ReplyDeleteFlip Books Software