Cultivating Architecture in an Agile World
summary
Argues that teams choose distributed services mainly for autonomy, claiming about 80% ownership driver rather than modularization, and warns that availability — not reliability — becomes the hard problem in distributed systems. Recommends concrete practices: fitness functions, ADRs, circuit breakers, game days, CDC into event-driven read models, and platform teams that treat dependencies as services. Proposes the zero‑downtime migrations pattern (compare new vs. legacy like GitHub’s Scientist with millions of comparisons) to safely evolve systems.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:26The role of architecture
- 3:44Modularization vs distribution
- 5:54Driving team autonomy
- 8:17Architecture as a tradeoff
- 10:39Autonomy and responsibility
- 13:21Cultivating architectural fitness
- 15:41Managing complexity and availability
- 17:53Resilient architecture patterns
- 20:29Embracing chaos engineering
- 22:40End-to-end verticalization
- 25:13Handling data and dependencies
- 28:32Team topologies and service levels
- 30:57Managing dependency pain
- 33:02Legacy decomposition strategies
- 38:15Conclusion
related talks
01h 00mAgile Architecture
38mAgile Architecture
47mAgile and Architecture: a meeting of the undead
49mAgile and Architecture: a meeting of the undead
44mHow Not to Die Trying to Evolve Your Architecture
37mArchitecting for Tomorrow: A Pragmatic Perspective
44mThe Art of Architecting for Scale
58mThe past, present and future of Architecture