Modularity in open systems
summary
Argues that software organizations are open sociotechnical systems so modularity must balance autonomy and interdependence, not just split work. Recommends teams own their own data, tools and post‑processes and use APIs to minimize coordination costs; cites Fred Emery’s DP1 vs DP2 shift from de‑skilled hierarchies to multi‑skilled networked teams and techniques like search conferences and participative design workshops to enact the change. Claims this reduces brittle central control and increases adaptive capacity; governance examples and blog references are given.
AI-written summary · about
chapters (14)
- 0:00Intro
- 0:49Overview
- 3:10Complexity
- 4:43Systems
- 5:43Complex systems
- 8:08System thinking
- 9:30System types
- 13:37Open social systems
- 14:45modularity
- 15:38Moderator
- 17:00Open System
- 17:44Biosphere
- 18:44Open System Theory
- 20:05Less Affairs
related talks
48mGood Fences Make Good Neighbours
43mGood Fences Make Good Neighbours
52mGood Fences Make Good Neighbours
51mModularization: Foundation of Microservices and Monoliths
01mMark Richards at DDD Europe
47mUnlock your autonomy. Improve your software design
43mAdaptive Socio-Technical Systems with Architecture for Flow
24mModularity Matters