逆康威定律

为了让组织更多地构建面向流程进行优化的有效软件系统，可以利用逆康威定律，在软件开发完成前重新配置团队的相互沟通方式。尽管一开始可能不顺利，但是通过管理层的推动意愿和团队意识，这种方法确实行之有效。

在2015年前后，逆康威定律在技术圈中得到了广泛关注，并被应用于很多组织中，尤其是在Nicole Forsgren博士、Jez Humble和Gene Kim的著作Accelerate：The Science of Lean Software and DevOps中证实了这种策略对于高效能组织的重要性之后。

我们的研究支撑了被称为“逆康威定律”的方法，即组织需要通过团队和组织结构的改进来实现预期的软件架构。目标是组织结构能够赋予团队完成从设计到部署的工作的能力，而无须团队之间进行高频沟通。

你还记得之前提到的单体数据库的反模式吗？我们曾经见过一些更加极端的案例，由于没有一个稳定的团队，以至于所有的变更都是通过临时项目（以外包的形式）完成的，导致应用和数据库深度耦合（共享数据和存储过程）。后来因为已经完全无法同其他业务逻辑进行解耦，阻碍了业务特定部分采用电子商务系统。相比于让空闲出来的内部工程师为了满足用户需求而在开发不同特性上疲于奔命，这种现实的技术债制约了组织快速交付的能力，在同竞争对手的竞争中处于下风。

那么，逆康威定律是如何把控团队或组织的走向，从而实现一个预期的软件架构的呢？

让我们通过一个有意简化过的在组织构建软件时使用康威定律的案例，来说明其中的理念和力量。假设有四个独立的团队，每个都由前后端开发工程师组成，他们分别负责系统的不同部分，然后对数据库管理员（DBA）提出数据库变更请求。这个变更流程的概念图如图2.1所示。

四个由前后端开发工程师组成的团队共同开发一个软件系统。前端开发工程师只需要同后端开发工程师沟通，而后端开发工程师需要同唯一一个DBA沟通数据库变更。

根据康威定律，软件架构自然而然地体现了团队设计，也就是每个团队都有独立的前端和后端模块，以及一个单点共享的核心数据库（参见图2.2）。

有四个独立应用，各自具备独立的用户界面和后端应用层，它们之间共享了一个数据库。这反映并且匹配了图2.1中描述的团队沟通架构，这个图是图2.1旋转了90°后的样子。

也就是说，一个共享的DBA团队很有可能会带来一个单一的共享数据库，而独立的前端和后端开发工程师推动了UI和应用层的前后端分离，这是沟通带来的自然结果。如果这个具有单一共享数据库，以及四个前后端分离应用的软件架构正是我们所需要的，那自然没有问题。

然而，如果我们并不想要一个单一共享数据库，那就麻烦了。因为康威定律的同态力会强烈地牵引软件架构“自然而然”地体现出当前的组织设计和沟通路径。

比方说，假如我们想在一些新的基于云的软件系统中使用微服务架构，那么每一个独立的服务都需要有属于它们自己的数据存储（参见图2.3）。

拥有四个独立服务的微服务架构，每个服务拥有自己的数据存储、API和客户端。

通过应用逆康威定律，可以设计我们的团队来满足软件架构的需求，也就是在各个独立的客户端应用和API开发团队里面增加一名数据库开发人员，而不是把他从团队中剥离出去（参见图2.4）。

组织设计体现了康威定律背后的同态力，从而带来了具有四个独立微服务的软件架构（这也是图2.3旋转90°之后的样子）。

根据康威定律，这种团队设计将“自然而然”地带来预期的软件架构。如果我们希望数据存储和业务领域进行绑定，那么我们就应该尽量避免单一的“扇入式”数据库管理员或团队存在（可行的方法是在软件开发团队中增加数据处理能力）。