Good book, looking forward to the 2nd edition coming soon. Good talks not just on software architecture but on how to be a software architect within an organization
Some misc bullet points:
- Architecture is the important stuff (whatever that is)
- Architecture is the stuff you can’t google
- Everything in software architecture has tradeoffs
- Chesterson’s Fence
- Respect past architecture decisions, assume they were made in a set of circumstances and constraints by smart people
- Architects need to aggressively expand their technical breadth. Moving things from unknown unknown to known unknown. Then can deep dive when needed.
- Avoid being the “Frozen caveman” - learn from past experience but don’t be trapped in the past. Need to expose yourself to new thinking not just rely on the same things
- Aim for the “least worst” architecture (because everything has tradeoffs)
- Software can be characterised by the “ilities”, i.e. scalability, availability, etc. And many of them are at odds with eachother.
- Leverage fitness functions, automate architectural decisionmaking. Example - enforcing p99 latency, linting rules, code coverage, etc. Let automated tools regulate the decisionmaking. I.e. netflix chaos engineering
- Conways law overrides almost everything
- Architecures, like art, need to be understood with the context of the era in which they were designed. Example - if software licenses were super expensive, you could never do something like microservices.