从康威定律看技术管理
前言
从单体架构到SOA架构,再到微服务架构,除了软件开发本身的技术驱动外,背后还有管理方法论的推动。这个视角是我担任技术管理职位之后才逐渐意识到的。本文就来分享一下我对系统架构与技术管理的一些思考,其背后的理论基础就是著名的『康威定律』。
1
康威定律缘起
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.
Conway, M. E., “How do committees invent? ” Datamation. 14,4(April. 1968 ), pp. 28-31.
中文意思是设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。可以简洁地表述为『组织架构等同系统设计』。下图是亚马逊、Google等知名互联网公司的组织架构抽象图,很好地说明了这一概念。
2015年,来自哈佛商学院和 MIT 的研究团队,用实际的研究和调查,证明了康威定律的普适性。在其发表的论文《Exploring the Duality between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis》中,他们分析对比了十几款开源和闭源软件,其中包括大名鼎鼎的Linux Kernel、MySQL、GNUCash等,验证了康威定律的正确性。
2
康威定律扩展
《RESTful Web APIs》的作者Mike Amundsen,在《远距离条件下的康威定律——分布式世界中实现团队构建》的一次技术分享中,从他的角度对康威定律进行了扩展,总结为四个定律。
第一定律
Communication dictates design
- Mike Amundsen.
组织沟通方式决定系统设计。沟通的问题会影响系统设计,进而影响整个系统的开发效率以及最终结果。《人月神话》这本书里有一句令人难忘的话:在应用项目后期加大人员的投资,会更加拖慢它的速度。书中总结出了随着人员的增加沟通成本呈指数增长的规律:沟通成本 = 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.
- Mike Amundsen
罗马不是一天建成的,学会先解决首要问题。敏捷开发巨头之一Erik Hollnagel 在他的书中阐述了类似的观点『问题太复杂?那么不妨忽略不必要的细节。没有足够的资源?放弃无用的功能』。
对技术管理的启示:不要试图一开始就设计完美的系统,先做出来,再不断迭代。好的架构不是设计出来的,而是跟随业务不断演化出来的。
第三定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization.
-Mike Amundsen
线型系统和线型组织架构间有潜在的异质同态特性。说的直白一点就是:想要什么的系统就搭建什么样的团队,有什么样的团队就会搭建什么样的系统。当系统是前后端分离的,对应的组织架构就是前端团队加后端团队;当团队按业务边界划分,系统也会拆分成微服务架构(如下图2所示),如下图所示。
对技术管理的启示:组织架构要与系统设计相匹配。
第四定律
The structures of large systems tend to disintegrate during development, qualitatively more so than small systems.
- Mike Amundsen
大系统总是比小系统更倾向于分解。一名经理管理的员工一般少于15个,团队大了组织结构就会拆分,团队负责的系统也随之分解。
对技术管理的启示:随着系统的不断演进,组织架构也需要随之迭代。
总结
系统设计不只是技术问题,也是管理问题。康威定律指出组织架构需要匹配系统架构;反过来,也可以通过调整组织架构来实现系统架构调整。对于技术管理者而言,在系统设计前首先要解决组织架构问题,并且在系统架构演进过程中,根据实际情况适当调整组织架构,使两者保持匹配。