康威定律和系统设计

最近看到一篇技术分享: 每个架构师都应该研究下康威定律,对其中提到的康威定律感到好奇, 特此记录分享。

Melvin Conway 在1968年发表的论文《 How Do Committees Invent》中指出:

系统设计的结构必定复制设计该系统的组织的沟通结构。


//维基百科
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

简单来说,系统设计(产品结构)等同组织形式,每个设计系统的组织,其产生的设计等同于组织之间的沟通结构。这时候不得不祭出这张图了:


结合上图和Amazon, Google等公司的产品设计,有没有体会到康威定律的精妙之处?

有意思的是该论点在提出多年内一直默默无名,后来在Brooks Law著名的人月神话中引用这个论点,“康威定律” 从此进入大众的视野。

团队和模块化

有经验的工程师可能注意到一个有趣的现象: 当所有员工在同一地点工作,开发的软件倾向于较少模块化,而若员工分散在不同的地点,开发的软件则倾向于更加模块化、耦合低。

当一支小型团队负责系统的设计与实现时,团队内部可以进行频繁的沟通。而随着团队变大、分布在不同地点甚至时区时,协调沟通成本急剧增加,最终各个地点不得不选择各自专门处理的一部分工作,并在团队之间形成更粗粒度的沟通机制。组织结构中的沟通路径会造就与之对应的粗粒度API,形成代码库各个大块之间的边界。

什么样的团队,产生什么样的架构

想要什么样的系统,你就搭建什么样的团队。如果团队分成前端团队,后台开发团队,DBA团队,系统就会变成下面的样子:

如果你的系统是按照业务边界划分的,大家按照一个业务目标去把自己的模块做出小系统,小产品的话,你的大系统就会变成下面的样子,即微服务的架构。

可见,组织和系统架构之间有一一映射映射关系,两者不对齐就会出各种各样的问题,例如集中式和严格职能(业务, Dev, QA, Deployment, Ops)的组织,很难推行微服务和DevOps,这样的组织职能之间都倾向于局部优化,无法形成有效的合作和闭环。

开放问题

  1. 我们每个小组内部的组织结构设计是什么样的?是否和小组所开发的系统架构相类似?
  2. 如果公司的系统架构图如下,其团队组织结构该如何构成呢?

参考

更多

请关注豆志昂扬微信公众号获取更多内容:

  • 直接添加公众号豆志昂扬
  • 微信扫描下图二维码;

推荐阅读更多精彩内容