前言
从单体架构到SOA架构，再到微服务架构，除了软件开发本身的技术驱动外，背后还有管理方法论的推动。这个视角是我担任技术管理职位之后才逐渐意识到的。本文就来分享一下我对系统架构与技术管理的一些思考，其背后的理论基础就是著名的『康威定律』。
康威定律缘起
1968年，马尔文·康威（Melvin Conway）在其论文《How Do Committees Invent?》阐述了系统设计与组织架构的内在联系。1975年，Fred Brooks在他著名的《人月神话》书中引用了这篇论文的结论，并命名为康威定律。Conway的论文原文表述如下：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
中文意思是设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。可以简洁地表述为『组织架构等同系统设计』。下图是亚马逊、Google等知名互联网公司的组织架构抽象图，很好地说明了这一概念。
2015年，来自哈佛商学院和 MIT 的研究团队，用实际的研究和调查，证明了康威定律的普适性。在其发表的论文《Exploring the Duality between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis》中，他们分析对比了十几款开源和闭源软件，其中包括大名鼎鼎的Linux Kernel、MySQL、GNUCash等，验证了康威定律的正确性。
康威定律扩展
《RESTful Web APIs》的作者Mike Amundsen，在《远距离条件下的康威定律——分布式世界中实现团队构建》的一次技术分享中，从他的角度对康威定律进行了扩展，总结为四个定律。
第一定律
Communication dictates design
组织沟通方式决定系统设计。沟通的问题会影响系统设计，进而影响整个系统的开发效率以及最终结果。《人月神话》这本书里有一句令人难忘的话：在应用项目后期加大人员的投资，会更加拖慢它的速度。书中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = 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 |
对技术管理的启示：在项目启动之初确定好项目人数，后期加人反而会拖慢进度。项目人数不是越多越好，根据实际系统设计需求确定人数。
第二定律
There is never enough time to do something right, but there is always enough time to do it over.
罗马不是一天建成的，学会先解决首要问题。敏捷开发巨头之一Erik Hollnagel 在他的书中阐述了类似的观点『问题太复杂？那么不妨忽略不必要的细节。没有足够的资源？放弃无用的功能』。
对技术管理的启示：不要试图一开始就设计完美的系统，先做出来，再不断迭代。好的架构不是设计出来的，而是跟随业务不断演化出来的。
第三定律
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 small systems.
大系统总是比小系统更倾向于分解。一名经理管理的员工一般少于15个，团队大了组织结构就会拆分，团队负责的系统也随之分解。
对技术管理的启示：随着系统的不断演进，组织架构也需要随之迭代。
总结
系统设计不只是技术问题，也是管理问题。康威定律指出组织架构需要匹配系统架构；反过来，也可以通过调整组织架构来实现系统架构调整。对于技术管理者而言，在系统设计前首先要解决组织架构问题，并且在系统架构演进过程中，根据实际情况适当调整组织架构，使两者保持匹配。
微信扫码关注公众号『互联网工匠』，获取更多优质技术文章。
