从康威定律看技术管理

前言

从单体架构到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个，团队大了组织结构就会拆分，团队负责的系统也随之分解。

对技术管理的启示：随着系统的不断演进，组织架构也需要随之迭代。

 

总结

系统设计不只是技术问题，也是管理问题。康威定律指出组织架构需要匹配系统架构；反过来，也可以通过调整组织架构来实现系统架构调整。对于技术管理者而言，在系统设计前首先要解决组织架构问题，并且在系统架构演进过程中，根据实际情况适当调整组织架构，使两者保持匹配。

 

 

微信扫码关注公众号『互联网工匠』，获取更多优质技术文章。