理解并使用康威定律

康威定律对于理解组织团队给软件系统带来的影响至关重要，这种影响长期存在却无人关注，因为软件系统已经变得比以往更加庞大和相互连接。但你有可能会怀疑一条1968年提出的关于软件架构的法则是否经得起时间的考验。

从微服务、云、容器到无服务，我们已经经历了漫长的过程。根据经验，这些创新可以帮助团队进行局部改进。但是组织规模越大，就越难享受这些技术红利。因为团队建立和交互的方式通常是基于过去的项目和/或传统技术来设计的。从组织结构图的设计来看，反映的即便不是几十年前，也是几年前的情况。

如果你曾经有过大型组织的工作经历，十有八九应该遇到过所有业务共享一个单体数据库的例子。当然，在DevOps和微服务获得广泛关注之前，单体数据库的优越性是有历史依据的，比如人和团队在技术栈分层方面专业性的不断提升。比如，项目导向、通过人力外包来降低成本或者缺乏必要经验的初级团队等，都导致了这些反模式长期存在。时至今日，这些反模式都被识别出来。单体数据库和应用的紧耦合也与之相关，导致了很小的业务逻辑变更都会影响到数据库（更多内容请参考第6章）。组织如果想要避免这种情况，不仅要具备良好的架构实践，也依赖于采用新的思维方式来设计现实中的团队结构和组件。

运动品牌公司阿迪达斯经历过一次有趣的转型，他们明确将康威定律视为组织设计的驱动力。Fernando Cornago（平台工程部高级总监）和Markus Rautert（平台工程和架构部副总裁）解释了IT部门的转型历程。他们曾经被视为成本中心，通过单一供应商来提供大多数软件（这个过程要求频繁的交付），以及极少数内部工程师（管理职责大于工程方面），到后来转变为一个产品导向的团队组织。阿迪达斯投入了80%的工程师资源，通过将跨职能团队和业务需求对齐，打造了公司内部的软件交付能力。剩余的20%工程师作为专职的中心平台团队，负责工程平台和技术解决方案，以及内部咨询和引入新的专业能力。结果是阿迪达斯的数字化产品发布频率提高了60倍，对软件质量也产生了积极影响。

除了这些被实践证明过的经验，越来越多的研究也证实了康威定律所揭示的趋势。哈佛商学院的Alan MacCormack和他的同事们对各种开源和闭源软件产品进行了研究，发现了“强有力的证据来支撑产品架构趋同于开发它们的组织结构的假设”。

对其他行业的研究，比如汽车制造业和飞机引擎设计领域，也都再一次证实了这个思想。事实上，已经有足够多的行业调研表明，康威定律所带来的同态力得到了广泛的应用。

Ruth Malan的这句话可以视为康威定律的现代版本：“如果系统的架构和组织结构不一致，那么组织结构将成为赢家。”Malan是想提醒我们组织在设计产品时往往要匹配或模仿真实的组织沟通结构。这一点无论是内部研发还是由外部供应商提供，对于任何组织设计和构建软件系统，都具有重要的战略意义。

特别是，当组织被划分为职能竖井（也就是团队按照专业职能来划分，比如QA、DBA和安全团队）时，难以面向端到端的工作流设计一个良好架构的软件系统。同理，如果一个组织主要根据不同地域的销售渠道来划分，那么就难以开发出一种有效的软件架构来面向全球所有区域提供多样性的软件服务。

为什么组织难以发现或者保持特定的架构呢？康威在他1968年发表的文章中给出了一些线索：“对于任何一个特定的团队或组织，那些必要的沟通路径不存在，导致了一系列可替代的设计方案难以有效落地。”

组织内部的沟通路径（无论是否和正式汇报线一致）严重制约了组织所能设计的解决方案的类型。但是我们可以将这一点作为自身的战略优势。如果我们想要避免一些过度关注技术内部实现的设计，就可以通过组织重组来实现这个目标。同样地，如果我们希望组织能够发现并采用一些特定的设计，这些设计更加有助于价值流动，那么我们同样可以通过组织重组来让它变为现实。当然，我们无法保证组织可以发现并使用我们想要的设计，但至少通过塑造沟通路径，我们可以使其变得更具可行性。

遵循康威定律来设计组织，已经成为一项核心的战略活动，大幅加速了有效软件设计的探索，并且避免了那些低效的设计。在第8章中，我们将深入讨论如何将康威定律牢记于心，并从战略上进行组织变革。