The (too) many faces of architecture
summary
Argues that architecture is not a mysterious role but a continuous, team-owned practice and backs that with concrete methods: use Conway's law to read organizational shapes in the code, map costly or hard-to-change areas with the circle of competence and favor architectural katas, small POCs, pair programming, code reviews, unit tests and quality gates. Cites projects that iterate the architecture multiple times (one needed four tries) and frames decisions around trade-offs, scope and measurable evolution.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 4:49Conway's law
- 8:44Architecture myths
- 15:17Multi-disciplinary thinking
- 21:57What an architect is not
- 24:02Architect role
- 29:44T-shaped skills
- 33:16Can every developer become an architect
- 35:03Architects and code
- 39:57Q&A
related talks
24mThe too many faces of Architecture
45mArchitecture: The Stuff That's Hard to Change
01h 02mThinking Like an Architect
33mSet Design: Putting the "Art" in "Architecture"
41mArchitecture and Agility: A Shared Skillset!
57mDomain Architecture Isomorphism and the Inverse Conway Maneuver
41mArchitecture Isn’t Kubernetes
01h 09mAgile Software Architecture