“组织形式等同系统设计”——这就是康威定律（Conway's Law）阐述的一个关键思想。Conway's Law (melconway.com)

其原话是这样的：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。

但是其思想启发远不止于此。

本文目录如下：

    1、团队组织＆产品架构设计

2、沟通成本 = n(n-1)/2

3 、孤岛系统的集成接口量

4、康威定律与微服务的合理性

 

1

团队组织＆产品架构设计

面试的时候，面试官问我们有什么要问的，实在想不出的时候，你就问问团队组织架构吧。

这不仅仅是关乎到自己入职后的汇报协作，同时也是对产品系统架构的预估。

为什么呢？因为组织结构往往代表一种协作分工，而分工的产物就是产品。

所以，团队组织形式，首先体现在系统上。

比如Apple的产品、微软等的产品脚骨设计，就能形象生动的理解这句话。

从这张图也可以看出：

• 亚马逊等级森严且有序；

  
  

• 谷歌结构清晰，产品和部门之间却相互交错且混乱；

  
  

• Facebook架构分散，就像一张散开的网络；

  
  

• 微软内部各自占山为王，军阀作风深入骨髓；

  
  

• 苹果一个人说了算，而那个人路人皆知；

  
  

• 庞大的甲骨文，臃肿的法务部显然要比工程部门更加重要。

多年前，更有人在《第一财经周刊》尝试着炮制了一份中国主要的科技公司的结构图—百度、腾讯、华为、联想、阿里巴巴、新浪。

结果发现，它们也是彼此风格迥异(和今天的实际情况已经不一样了)：

• 华为，技术创新引发矩阵结构变化；

• 阿里巴巴，马云的影子无时无处不在；

• 新浪，依托微博画了一张大饼；百度崇尚简单；

• 联想，大小通吃但又左右互搏；

• 腾讯，产品与部门关系千丝万缕，QQ是所有产品与服务的基石。

这给我们的启发就是，想要什么样的系统，就搭建什么样的团队。

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

这个思想，其实就来自于康威定律。

2

沟通成本 = n(n-1)/2

《人月神话》中最著名的一句话就是:

Adding manpower to a late software project makes it later --Fred Brooks, (1975)

之所以这样，是因为沟通成本 = n(n-1)/2。

沟通成本随着项目或者组织的人员增加呈指数级增长。举个例子：

• 5个人的项目组，需要沟通的渠道是 5*(5–1)/2 = 10
• 15个人的项目组，需要沟通的渠道是15*(15–1)/2 = 105
• 50个人的项目组，需要沟通的渠道是50*(50–1)/2 = 1,225
• 150个人的项目组，需要沟通的渠道是150*(150–1)/2 = 11,175

为什么这样呢？国外的研究：灵长类的大脑容量和其对应的族群大小有一定关联：

从而推测出人类的大脑智力只能支持我们维系这么多的关系:

• 亲密（intimate）朋友: 5
• 信任（trusted）朋友: 15
• 酒肉（close）朋友: 35
• 照面（casual）朋友: 150

再多的化，沟通的问题，会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。

150也就成了很多设计的参标，比如某系统的购物车最大允许200个商品（涵盖150）。

所以，一个大的组织因为沟通成本/管理问题，总为被拆分成一个个小团队。

每个经理都被赋予一定的职责去做大系统的某一小部分，他们和大系统便有了沟通的边界。

3

孤岛系统的集成接口量

说一个案例：

随着医院信息化建设的不断完善，医院逐步上线了 HIS、EMR、PACS、LIS 等多个业务系统。

由于这些业务系统由不同厂家开发，各个系统拥有不同的操作系统、数据库，进而导致不同业务系统之间需求调用复杂、接口数量多且无统一标准、数据交互效率低下、维护困难等问题 。

正如人月神话提出的，随着项目或者组织的人员增加呈指数级增长，沟通成本 = n(n-1)/2，传统模式下各个孤立系统对接时候的接口开发最大数量也是N*(N-1)/2。

这就导致实现成本很高，于是出现很多集成平台。

集成平台的重要性在于，其不仅能够在各个系统之间实现统一集成和交互，同时为数据集成提供了可能。

通过将各个系统产生的数据集中存储并重新组织形成医院的数据仓库，集成平台为下一步数据分析创造条件，即充分挖掘数据价值进而形成一系列数字化应用支撑智能化决策，帮助医院实现真正数字化转型。可以说，集成平台是医院数字化转型的重要基础。

市场出现很多超融合架构承载集成平台，相较传统架构具备高可靠、高性能、简单敏捷等多种优势，将会成为企业集成平台基础架构选型的一个不可忽略的选项。

所以大的系统也会因此被拆分成一个个小团队负责的小系统（微服务是一种好的模式）。

4

康威定律与微服务的合理性

微服务是指将应用功能最小化，原子化，尽可能减少应用服务之间的耦合，而后通过不同微服务组合出不同的功能，提供给用户。最大化服务的可重用性。

康威定律其实在半个世纪前就奠定了微服务架构的理论基础。

如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效。

复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的。

带来的具体的实践建议是：

在对应下衡量微服务的标准，我们很容易会发现他们之间的密切关系：

• 
  

• · 分布式服务组成的系统

• · 按照业务而不是技术来划分组织

• · 做有生命的产品而不是项目

• · Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）

• · 通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。

• · 自动化运维（DevOps）

• · 容错

• · 快速演化

微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

小结

康威定律可归纳一些核心观点，如下：

• 第一定律：Communication dictates design（组织沟通方式会通过系统设计表达出来）

  
  

• 第二定律：There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做的完美，但总有时间做完一件事情）

  
  

• 第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization（线型系统和线型组织架构间有潜在的异质同态特性）      

   

• 第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系统组织总是比小系统更倾向于分解）

给我们的启发是：

• 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理。

  
  

• 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计。
  

  
  

• 我们要用一切手段提升沟通效率，能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。

  
  

• 你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。
  

  
  

• 做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的Bezos有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7，8人左右（包含前后端测试交互用研等，可能身兼数职）。

扫码加产品社群