CONWAY'S LAW

康威定律

组织结构如何塑造软件架构

PART 01

核心观点

技术方案可以写在文档里，但日常沟通方式才是持续塑造系统的力量。

01

软件架构不仅是技术设计的结果，也是组织沟通结构的外在映射

一个组织如何划分团队、谁能够直接沟通、哪些部门需要通过正式流程协作，都会逐渐反映到软件系统中。组织内部的沟通关系，最终往往会变成系统中的模块边界、接口关系和依赖结构。

因此，即使架构师在图纸上设计了一套理想架构，真正落地的系统仍可能朝着组织结构所允许的方向演化。技术方案可以写在文档里，但日常沟通方式才是持续塑造系统的力量。

02

划分团队的同时，也在事实上划分软件系统

项目开始时，管理者通常先根据专业、职能或业务范围分配人员，例如建立前端团队、后端团队和数据库团队。这样的组织方式看似只是人员管理，实际上已经预先决定了系统最可能出现的边界。

每个团队会围绕自己的职责建立代码、流程和决策权，团队之间的协作则会被固化为系统之间的接口。团队在哪里分开，软件通常也会在哪里分开。

03

部门之间的沟通障碍，会转化为系统模块之间的集成障碍

如果不同团队目标不一致、信息无法自由流动，或者必须经过复杂流程才能协作，那么它们负责的系统模块也很难形成顺畅的连接。

例如，前端、后端和数据库分别由三个独立部门负责，最终可能形成清晰的三层架构，但每一层都按照各自部门的目标独立设计。技术边界虽然明确，跨层集成却可能十分痛苦，因为系统接口背后实际对应的是组织之间没有解决的协作问题。

04

沟通路径不仅影响显式接口，也会影响系统中隐含的耦合关系

团队成员能够频繁交流时，更容易形成共同的业务理解、术语体系和设计假设，他们负责的代码也更容易产生紧密联系。反过来，缺少交流的团队很难建立这些共享认识，只能依赖更正式、更有限的接口进行合作。

因此，系统耦合不只是函数调用、数据库访问或网络请求的问题，也来自开发者之间共享了多少背景知识，以及他们是否能够及时协商设计变化。

05

想获得某种软件架构，需要建立与之相匹配的团队结构

如果企业希望建设由独立服务组成的架构，却仍然按照前端、后端、测试和数据库等技术职能组织团队，那么每项业务功能都要跨越多个部门才能完成，服务很难真正独立。

更可行的方式是建立围绕业务能力组织的跨职能团队，让一个团队拥有完成某项业务功能所需要的全部能力，并对相应服务承担端到端责任。团队能够独立决策、开发和部署，系统中的服务才更可能形成类似的自主性。

06

“逆康威操作”是主动利用康威定律，而不是试图摆脱它

康威定律并不意味着组织只能被动接受现有架构。企业可以先确定希望形成的系统结构，再有意识地调整团队边界、责任范围和沟通方式，使组织结构推动目标架构的形成。

这种做法被称为“逆康威操作”。它不是仅靠架构规范要求团队遵守设计，而是通过改变实际协作关系，让理想架构成为组织最自然、阻力最小的产物。

07

小型、自治、跨职能团队更容易形成模块化的服务架构

规模较小的团队能够保持密集而直接的沟通，并对明确的业务范围负责。当不同团队分别拥有独立服务，并通过清晰的接口协作时，组织结构便会推动系统形成相对独立的模块。

亚马逊的“两张披萨团队”就是这一思路的典型案例：每个小团队负责特定服务，团队之间通过明确的服务接口协作。康威定律可以解释为什么这种组织方式容易产生面向服务的系统结构。

08

按业务功能组织团队，通常比按技术层级组织团队更有利于端到端交付

Spotify 模型中的 Squad 围绕产品功能或业务领域组织，并拥有完成工作的多种专业能力。相比之下，按照分析、设计、开发、测试等阶段划分团队，会让一项功能在多个部门之间不断移交。

跨职能团队减少了交接和等待，使产品功能、团队责任与系统模块更容易保持一致。不过，这种模式只有在解决真实的协作问题时才有效，机械复制团队名称和组织形式并不会自动产生相同结果。

PART 02

二、进一步洞察

有效的做法是把架构演进与组织演进看作同一个持续过程。

INSIGHT 01

组织设计本身就是架构设计的一部分

建立团队、分配职责和确定汇报关系，不能被视为技术架构之外的管理事务。团队结构一旦确定，某些设计方案就会变得容易实施，另一些设计方案则会因为缺少必要的沟通路径而难以推进。

因此，在系统设计完成后再安排团队，往往已经太迟。系统边界和团队边界需要在项目早期共同设计。

INSIGHT 02

系统中难以治理的接口，背后经常存在没有解决的组织关系

当两个模块之间长期存在职责不清、接口反复变化、集成成本过高等问题时，原因未必只是代码质量不足，也可能是负责这些模块的团队缺乏共同目标、稳定沟通机制或清晰的责任边界。

单纯重写接口或增加技术规范，无法自动消除这种问题。只有同时调整团队责任和协作方式，技术接口才可能真正稳定下来。

INSIGHT 03

微服务首先是组织自治问题，其次才是服务拆分问题

把一个单体系统拆成多个进程或代码仓库，并不意味着企业已经获得了微服务架构。如果多个服务仍然需要大量跨部门协调、共同发布，或者依赖同一支中心团队完成关键工作，那么这些服务在组织层面仍然没有独立。

真正的服务自治需要对应的团队拥有明确责任、完整能力和独立交付权限。缺少组织自治，技术上的服务拆分只会增加接口数量和协调成本。

INSIGHT 04

组织越庞大、沟通结构越僵化，康威定律的影响越明显

小团队可以通过非正式交流跨越岗位边界，因此组织结构未必会立即固化为明确的系统边界。随着人数增加，沟通路径迅速变得复杂，组织不得不通过部门、层级和流程限制交流范围。

这些限制随后会被复制到系统中，使大型组织更容易形成边界僵硬、接口复杂和协调困难的软件结构。

INSIGHT 05

增加人员并不等于按比例增加系统设计能力

人员增加会带来更多专业能力，也会同时增加沟通和协调成本。为了管理更多人，组织通常需要进一步分组和授权，而这些分组又会在系统中形成新的边界。

系统设计工作不能简单按照人数或工时进行线性计算。过早扩张团队，可能不是加快设计，而是迫使一个原本可以保持整体性的系统过早碎片化。

INSIGHT 06

重组团队不能立即修复已经固化的旧架构

对于已经运行多年的系统，代码结构、数据边界和部署方式已经形成稳定依赖。此时仅仅调整组织架构，反而可能造成新的团队边界与旧代码边界不一致，让开发和维护更加困难。

组织调整与系统重构需要同步、渐进地进行：一边重新划分团队责任，一边逐步调整代码和服务边界，并根据实际反馈持续修正。

INSIGHT 07

软件架构与组织结构不是一次性对齐，而是需要共同演化

企业业务会变化，系统架构也会变化，团队的职责和沟通方式必须随之调整。如果组织结构长期固定，而系统不断扩展，二者之间会逐渐出现错位；如果频繁重组组织，却不处理已有技术边界，同样会增加摩擦。

有效的做法是把架构演进与组织演进看作同一个持续过程，让系统模块、团队责任和业务价值流长期保持相对一致。