多年前，Melvin Conway观察到组织的结构将对他们创建的任何系统产生强烈影响。在他的“如何做委员会发明”中，他写道：
“任何设计系统的组织（这里只是更广泛地定义信息系统）将不可避免地产生一种设计，其结构是组织通信结构的副本。”
当时，哈佛商业评论基于他没有证明他的假设的事实拒绝了他的原始论文。尽管如此，这一观察结果已被称为康威定律，同事和我自己的集体经验一次又一次地强化了这一陈述的真实性。但你不必接受我们的话！
在“探索产品与组织架构之间的二元性”中，哈佛商学院的一项研究对不同的代码库进行了分析，看看它们是否可以证明康威最初的假设适用于软件系统。在其中，他们采用了多个为解决相同目的而创建的软件示例（例如文字处理，财务管理和数据库软件），并比较了松散耦合的开源团队创建的代码库，以及由紧密耦合的团队创建的代码库。 。他们的研究发现，通常位于同一地点，专注的产品团队创建的软件更倾向于紧密耦合的单片代码库。而开源项目产生了更多模块化，分解的代码库。
几年来，组织已经理解了组织结构与他们创建的软件之间的这种联系，并且已经采用新的结构来实现他们想要的结果。例如，Netflix和亚马逊围绕多个小团队建立自己的团队，每个团队负责整个系统的一小部分。这些独立团队可以拥有他们创建的服务的整个生命周期，为拥有更多整体代码库的大型团队提供更大程度的自主权。这些具有独立关注点的服务可以彼此分开更改和发展，从而能够更快地提供对生产的更改。如果这些组织采用了更大的团队规模，那么已经出现的更大的整体系统就不会给他们提供相同的实验，适应和最终让客户满意的能力。
您可能会在自己的组织中发现您的结构和软件不一致的紧张情况。您可能已经看到了分布式团队尝试在同一个整体代码库上工作所涉及的挑战。在这里，Conway所指的通信路径与代码本身形成对比，其中单个代码库需要细粒度的通信，但是分布式团队只能进行粗粒度通信。在出现这种紧张局势的情况下，寻找机会将整体系统分散在组织边界附近通常会产生显着的优势。
在之前的技术雷达中，我们强调了微服务的日益普及，这些微服务越来越多地被那些希望提高团队自主性和提高变革速度的组织所采用。 Martin Fowler和James Lewis的文章更深入地讨论了这一主题，强调了这些架构允许组织更灵活地将系统架构与团队结构保持一致，以确保Conway法律适合您。在Tech Radar的下一版中，我们将讨论微服务日益增长的影响力的反映，从Packer或Docker等基础设施技术到服务发现工具Consul，或者像流行的DropWizard或相当新的SpringBoot这样的微容器。我们还将讨论相反的情况 - 组织改变他们的团队结构以适应他们的IT系统。
我们完全希望看到更多技术和支持技术出现以实现微服务架构，我们将在未来几个月内跟踪这些。与此同时，如果您想了解更多，请注册最新的Tech Radar，查看Martin和James关于微服务的文章，或者来自O'Reilly，Building Microservices的书。
原文：https://www.thoughtworks.com/insights/blog/demystifying-conways-law
本文：
讨论：请加入知识星球或者小红圈【首席架构师圈】