背景

目前在看架构方面的资料，了解到了一个很受用的概念，就是今天所说的“康威定律”。可以说这个概念解释了我很多的疑惑，也让自己对架构有了更多的理解。所以特定分享自己的感悟和心得。

什么是“康威定律”

康威定律是 50 年前（1967 年）由 梅尔文·康威 提出的，最初的说法（也是康威定律的核心）是：

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

即：一个组织的系统通常被设计成这个组织通信结构的副本

这句话的意思就是企业或者团队设计出来的系统，等同于其内部的沟通结构，如下图：

这也就是为什么以前会出现互联网基因论：阿里适合做交易，腾讯适合做社交。

当然很多同学在听到这句话和我一开始的想法是一样的，那就是在瞎扯，腾讯现在微信支付做的也不错啊，阿里不是也有钉钉么。

但是我们看到即使微信支付成功，其依托的也是其背后的社交产品--微信，而且微信支付背后的生态远远不如支付宝。而钉钉也是如此，目前的成功的原因正如其自己说的，那就是放弃模仿微信或者 QQ，瞄准的是企业或者团队的内部交流工具，这和阿里先天的效率基因是吻合的。所以上面的例子不仅没有反驳互联网基因论，相反其更加印证了这个观点。

而这个观点在 50 年前就被康威提了出来，那就是：产品是其背后组织的沟通。

四大定律

康威定律在提出后，被很多大牛都引用和拓展过，其中最为经典的就是《人月神话》中引申出来的四大定律。

组织沟通方式会通过系统设计表达出来

这个是康威定律本身，其意思简单说就是，组织是什么样，做出来的产品就是什么样。这也是为什么阿里在引入中台之前首先做的就是更改组织结构，先将内部的组织结构调整，才能做出中台。而其他公司只学习中台的概念或者技术，则会发现在落地的时候处处掣肘，以至于无法实现。

同样的道理，我们可以从一个公司的产品去理解其背后的组织结构。我们会发现市场上很多的产品天马行空，形态没有下限，也没有上限。其随意的背后来自于其背后组织的涣散，很有可能内部的组织沟通方式不是严格的职责划分，而是面向老板开发。

时间再多一件事情也不可能做的完美，但总有时间做完一件事情

这个是《人月神话》的核心理念之一，我们不可能一下子做出很完美的产品，但是我们可以做出一个可用的产品，也就是 MVP 产品（最简可行产品）。这也是敏捷开发和迭代的理论基础。

所以在实际工作中，我们不需要一开始就试图打造完美的设计，整理出完美的流程：

• 文档可以暂时不完美，但也不能没有，即使拍张照片也可以

• 产品一开始可以不完美，但是我们可以做到一个可以跑通的产品

• 代码也可以不完美，存在 bug 无可厚非，但是我们要去不断迭代

先把事情做了，再去逐步完善。

线型系统和线型组织架构间有潜在的异质同态特性

异质同态指的是系统和组织虽然是两个东西，但是有相同的结构。所以系统是啥样，组织也就得变成那个样子。这个比较好理解，做过技术管理的人在设计组织架构的时候都会参照系统的架构来设置。

比如公司如果是单体架构，那就一个开发组就行了；但是如果是前后端分离，那么必然就会拆分为前端组和后端组，分别进行管理。这就是所谓的异质同态。如果系统和组织的结构不匹配，那么将会是灾难。你想象一下系统是前后端分离，但是压根就没拆分前后端的岗位是啥情况？

大的系统组织总是比小系统更倾向于分解

这个是目前大部分公司采用的方式，因为随着业务的增长，系统将会变得复杂。那么就需要增加人手，这时沟通成本和管理成本也随之增加。那么大部分公司都会采用分而治之的方式。所以，一个大的组织因为沟通成本/管理问题，总会被拆分成一个个小团队。

那么根据康威定律，组织的沟通方式会在系统设计上体现。所以每个经理都被赋予一定的职责去做大系统的某一小部分，他们和大系统便有了沟通的边界，所以大的系统也会因此被拆分成一个个小团队负责的小系统。而这就是我们现在经常说的微服务架构。

认清组织的沟通方式

所以根据康威定律，系统设计应当与组织沟通方式贴合。这个世上没有完美的系统设计，只有最为合适的系统设计。什么时候最为合适的系统设计，那就是业务-组织-系统都完美贴合。如果是业务导向的，那么就要去调整组织结构。如果是组织导向的，那么就要去调整业务目标。而现实中很多时候，都是三者不相贴合，这样就会在实现的时候互相掣肘，严重影响最终的效果。

虽然在很多讲解康威定律的文章中，都会在最后用康威定律来解释微服务架构的合理性，因为在解决沟通成本和提升效率上，微服务是最为贴合的。但是不能盲目追求微服务的系统，因为如果你的业务或者组织结构并不适合微服务架构，那么微服务给你带来的复杂度大于收益。

加速产品上市的平台团队

在 ThoughtWorks 最新的调研中，提到了目前正在崛起的平台团队模式。其原文如下：

越来越多的组织正在采用平台团队的理念来开发产品，即成立一个专门团队，来创建和支持内部平台功能（如云原生、持续交付、现代化的可观测性、认证和鉴权模式、服务网格等），并使用这些功能来加速应用程序开发，降低运维复杂性，并缩短产品上市时间。这种日趋成熟的做法值得欢迎，所以我们早在 2017 年，就将该技术引入技术雷达。但是随着成熟度的提高，我们发现组织在应用这项技术时，应避免使用一些反模式。例如，“用一个平台来统治一切”，可能并不是最佳选择。“构建一步到位的大平台”，可能要过数年后才能交付价值。本着“一旦建好，就有人用”的初衷，到头来可能却是巨大的浪费。相反，使用产品思维，有助于根据产品客户的需求，来弄清每个内部平台所应提供的服务。但如果让平台团队只解决技术支持工单系统中所提交的问题，那么这种做法就又产生了老式的运维孤岛团队，出现相应的需求优先级失调的弊端，如反馈和响应缓慢，以及争夺稀缺资源等的问题。此外，我们还看到一些新工具和集成模式涌现出来，以有效划分团队和技术。

这个的原因是因为目前随着云原生，DevOps 等技术的成熟，成立一个专门的平台团队可以减少内部的沟通成本，加速产品的研发。而这个组织结构产生的原因是因为目前云原生等技术的成熟催生了新的系统设计模式。与之而来的是带动了组织结构的变化。

但是这个里面也提到了，虽然平台团队越来越受欢迎。但是如果组织没有适应好，那么就会适得其反，增加内耗和掣肘。所以要学会根据自己所在团队的沟通方式来选择是否采用平台团队的模式。

总结

很多文章都会说架构师不仅仅要懂代码或者设计模式，还要懂很多额外的东西。因为这些额外的东西很多时候恰恰是最影响架构实现。康威定律在 50 年前解释了目前的微服务兴起的原因，每一位架构师都应该去了解。

如果喜欢我的分享，欢迎关注“雨夜随笔”

原文链接：为什么每个程序员都应该了解“康威定律” (qq.com)