Managing architecture
summary
Compares two concrete systems for steering architecture: a community architecture guild that conserves an early vision through meetups and principles, versus a dedicated enabling team that runs regular check‑ins, checklists and cookbooks, builds a portal, maintains a tech radar and actively closes capability gaps. Claims the enabling team wins for transformation while the guild suits preservation, emphasizes an intent to culture (teams declare intentions for visibility), and shows these practices actually reduce risky blindspots without central approvals.
AI-written summary · about
chapters (13)
- 0:00Software architecture for leaders
- 1:27Architecture and team scalability
- 3:12Ivory Tower architect myth
- 5:20Team autonomy versus alignment
- 8:11Architecture Guild approach
- 11:01Transforming legacy systems
- 14:12Enabling teams for capability
- 17:45Strategic oversight in architecture
- 20:14Culture of transparency and intent
- 22:18Supporting teams beyond dumping
- 24:45Trust teams over centralizing
- 26:08Who drives architecture
- 26:51Choosing approach for context
related talks
24mThe too many faces of Architecture
30mCommunicating and documenting architectural decisions
40mPractices from trenches for embracing evolutionary architecture in wild
24mBusiness Value Over Architecture?
40mThe (too) many faces of architecture
50mCoevolution of Architecture & Code - Closing The Gap
47mArchitecture as Code or How to Survive Legacy and Keep Your Sanity
45mArchitecture: The Stuff That's Hard to Change