Architecture is Designing Knowledge Flow
summary
Argues that success comes from designing knowledge flow not valuing only individual knowledge stock; shows how monolith→microservices often reproduces the same coupled thinking, cites the beer game to explain blame and counterintuitive fixes (adding people makes late projects later). Recommends architecting stable capabilities (e.g., process transactions, distribute content) over platforms, designing source of truth in motion and observable CI/CD (Jenkins→CircleCI example), warns Kubernetes is a tool not a mandate and claims leverage-point wins take ~18 months to be accepted.
AI-written summary · about
chapters (16)
- 0:00Architecture and knowledge flow
- 2:13Linear thinking in distributed systems
- 4:42Systems producing results
- 8:24Blame game and human complexity
- 13:03Counterintuitiveness in changes
- 15:12Avoiding the factory trap
- 17:40Context over universal solutions
- 19:48System purpose before design
- 21:58Relationships in systems
- 24:31Growth mindset and decisions
- 27:47Knowledge flow vs stock
- 30:37Reasoning about reality
- 32:08Architecting capabilities
- 36:21Leverage points in systems
- 39:33Patience and 18-month rule
- 41:45Q&A Kubernetes serverless
related talks
43mSoftware Architecture, Design Thinking & Knowledge Flow
58mArchitecture isn't Kubernetes
41mArchitecture Isn’t Kubernetes
17mSAG Expert Interview #01: Designing Knowledge Flow & Inclusive Architecture
43mAdaptive Socio-Technical Systems with Architecture for Flow
46mArchitecture Transformation Challenges
44mDeliberate Architecture
45mArchitecture: The Stuff That's Hard to Change