Software Architecture, Design Thinking & Knowledge Flow
summary
Argues that software architecture must stop prescribing one-size-fits-all fixes and instead map real relationships: a bank example where weekly cross-team meetings make things worse, microservices deployed as a panacea that fail to deliver product velocity, and legacy coupling that survives migrations. Recommends iterative greenhouse experiments, treating eventual consistency as acceptable design tradeoff, measuring whether changes improve the organization’s knowledge flow, and aiming to make the architect role progressively obsolete by improving system-level decision criteria.
AI-written summary · about
chapters (7)
- 0:00Intro
- 0:40Role of a software architect
- 10:05A new world for software engineering?
- 24:15Consistency & consensus
- 34:11Software design & knowledge flow
- 39:54Q&A
- 42:16Outro
related talks
49mArchitecture is Designing Knowledge Flow
57mSoftware Architecture: The Hard Parts
45mFive things every developer should know about software architecture
49mWhy software architects fail: and what to do about it
37mSoftware Architecture for Humans!
51mSoftware Architecture for Humans!
41mThe lost art of software design
08mLightning talks – 101 Things Software Never Learnt