Making architecture decisions, the Agile Way
summary
A concrete claim: record significant design choices as architectural decision records (short markdown files) so future devs see not just the outcome but the context, options and tradeoffs; a painful case study shows a six‑person team that rewrites a monolith into microservices vs monolith and pays extra networking and ops complexity without team benefit; practical rules: make decisions store ADRs in git just‑in‑time, keep them short, list options and pros/cons, and render simple diagrams (mermaid) alongside code.
AI-written summary · about
chapters (12)
- 0:00Welcome
- 1:33Early career struggles
- 6:27Agile vs waterfall
- 7:07Legacy architecture challenges
- 10:24Microservices mistakes
- 13:32Agile manifesto balance
- 17:46Agile architecture design
- 22:05Recording decisions with ADRs
- 31:05Benefits of architectural decision records
- 34:58ADR implementation tips
- 37:24Key takeaways
- 39:36Q&A
related talks
30mCommunicating and documenting architectural decisions
38mAgile Architecture
39mOne Does Not Simply Make Architecture Decisions Alone: ADRs and Architec
14mArchitecture Decision Records: Make Peace with Your Docs
25mThinking Architecturally
01h 00mAgile Architecture
48mDown the Ivory Tower towards Agile Architecture
37mArchitecting for Tomorrow: A Pragmatic Perspective