康威定律与逆康威定律

康威定律随着微服务架构兴起的步伐慢慢复苏,重新进入人们的视线,但他的威力远远不仅限于简单的指导如何拆分微服务,不管是整个团队的战力,还是架构方案能否顺利落地都起着重要的作用。

康威定律

先回顾一下什么是康威定律:1968年,计算机系统研究院的梅尔康威在Datamation杂志上发表了一篇论文How Do Committees Invent?

这篇论文中有一句话被总结为康威定律:“设计系统的组织由于受到约束,这些设计往往是组织内部沟通结构的副本。”

下面先通过一次切身经历来阐述定律如何发挥威力,以及如何通过逆康威定律得到我们想要的架构方案

起初我带领一支团队负责一个业务,先称它为APP1,经过一段时间,老板找我谈话,说:“APP1在你的带领下,运行得不错,应该承担更大的责任,后面APP2团队也由你负责”。

经过一段时间的迭代,APP2需要一个配置服务,支撑差异化运营

APP2架构师根据最新业务需求,提出了给APP2增加一个配置服务,对于APP2来讲,架构师都无需赘述,此架构方案无疑是合理的

但从整体看APP1已经有配置服务

此时就有了两个方案:

  1. 按架构师规划,APP2构建新的配置服务
  2. 增强APP1的配置服务,让它同时支撑APP1和APP2

怎么决择呢?

从架构角度,方案一似乎更有优势,独立,两个APP之间也不会相互干扰,原先的配置服务也无需改动,相对去改造一个旧系统,构建新系统负担还小一些

但从组织结构讲,组织效能角度也更高效,大局出发,也不需要两个相似的配置服务,组织结构与架构结构也更有同态性

此时,康威定律就发挥了至关重要的作用:“如果系统的架构和组织结构不一致,那么组织结构将成为赢家”


当我在计划着进一步整合两个团队时,事情发生了变化,老板又找我谈话了,“经过这段时间,发现你带两个团队有些吃力,这样吧,以后你就只负责APP2团队”

随着业务的继续开展,发现了个问题,当APP2团队需求需要变更配置服务时,为难了

APP1使用配置服务深度和广度都高于APP2,所以在划分时,配置服务归于APP1了,之前都是同一个大团队,资源协调很简单,内部沟通很容易

此时怎么办?

原先团队内部的沟通,需要跨团队沟通了,再简单的一次变更,都需要提前沟通,协调排期,制约了高效迭代交付能力

所以APP2团队不得不剥离APP1的配置服务,另起炉灶,回到当初架构师的方案一

这其实还是康威定律发挥着威力:组织内部的沟通路径(无论是否和正式汇报线一致)严重制约了组织所能设计的解决方案的类型

逆康威定律

这是ThoughtWorks技术总监James Lewis突发奇想地提出的,组织要根据他们想得到的软件架构来设计团队结构,而不是期望团队盲从一个被设计好的团队结构

其核心观点在于,将软件架构看作一个独立的概念,认为它可以被孤立设计,然后交由任何团队来实现,这从根本上就是错误的

我们把上面的示例,顺序倒置过来,就是逆康威定律。

我详细阐述下:

刚开始,APP1和APP2是两个独立完整的团队,都有各自的配置服务,也就是

虽然他们功能相似,但由于在两个团队里面,与组织结构和沟通路径都是匹配的

从公司全局架构看,发现配置服务只需要一个就够了,推倒烟囱式架构,整合资源,配置服务中台化,这也是近些年各公司崇拜的中台文化

怎么办呢?简单啊,提取共性,抽象整合呗。

现实没那么轻松,如果两大APP团队,是支撑公司盈利的两大业务,营收压力也很大,基本上整合是句空话,看看有多少公司的BU都是各自为战,烟囱式系统一个比一个强悍,谁能动得了?

此时怎么办?整合组织结构,让两个团队组合成更大的团队,拥有独立的架构团队,团队内部自己就会催生出整合的力量

再看一个示例,假设有四个独立团队,每个都由前后端开发工程师组成,他们分别负责系统的不同部分,然后对DBA提出数据库变更请求。

如果这四支团队独立的前端和后端开工程师推动了UI和应用层的前后端分离,而有一个共享的DBA团队,那么很可能会带来这样一个单一的共享数据库。

因为康威定律的同态力会强烈地牵引软件架构“自然而然”地体现出当前的组织设计和沟通路径。

当我们在使用微服务架构时,每个独立服务都需要有属于自己的数据存储。

通过应用逆康威定律,可以在各个独立的客户端应用和API开发团队里面增加一名数据库开发人员,那架构结构自然就体现出来了。

总结

想想架构风格千千万万,为什么分层架构却是最流行的,也是最容易实践成功的,因为有独立的前端团队,后端团队,基础服务团队,对于业务数据流向,正好也是从UI发起,逻辑层处理,数据库存储,组织结构与架构结构是匹配的。这就是康威定律的威力。

组织结构和团队间真实的沟通路径会直接影响所构建系统的架构。如果有四个小组合作开发一个编译器,那么你将得到一款具有四个步骤的编辑器。对于一家软件产品公司来说,组织结构预示着产品架构。

过去很多组织结构调整的潜在目标都是为了减少员工或者围绕管理者和领导者的权势建立山头。可对于一家软件公司,势必慎重,必须要考虑架构,更可以应用逆康威定律:设计团队满足理想的软件架构

简而言之,在设计软件架构或进行组织结构调整时,将康威定律纳入考虑因素之中,就能够受益于兼顾软件架构和团队设计的同态力。

公众号:码农戏码
欢迎关注微信公众号『码农戏码』