康威定律的各种解读 - ThinkingLabs

随着时间的推移，不同的人以各种不同的方式阐明了康威定律。这是我最近在阅读康威定律文献时发现的变化的概述。

Melvin Conway对康威定律的原始定义：

设计系统的组织被限制生产设计，这些设计是这些组织的通信结构的副本。

尤尔登和康斯坦丁更坚定地重新表述了康威定律：

组织设计的任何系统的结构都与组织的结构同构。

– Edward Yourdon 和 Larry L. Constantine，结构化设计，1979

埃里克·雷蒙德 (Eric Raymond) 重申了康威定律如下：

软件的组织和软件团队的组织将是一致的。

——埃里克·雷蒙德，新黑客词典（第 3 版），1996 年

COBOL 示例：

如果您有 4 个小组在开发一个编译器，您将获得一个 4-pass 编译器。

——埃里克·雷蒙德，新黑客词典（第 3 版）p。124., 1996

将Tom Cheatham 的修正案添加到康威定律中。

如果一组 N 人实施 COBOL 编译器，则将有 N-1 次通过。小组中的某个人必须是经理。

——埃里克·雷蒙德，新黑客词典（第 3 版）p。124., 1996

James Coplien 和 Neil Harrison 表示如下：

如果一个组织的各个部分（例如团队、部门或分部）没有密切反映产品的本质部分，或者如果组织之间的关系没有反映产品部分之间的关​​系，那么项目就会陷入困境……因此：确保组织与产品架构兼容。

- James Coplien 和 Neil Harrison 敏捷软件开发的组织模式，2004

艾伦·凯利的推论：

组织设计就是系统设计。

——艾伦·凯利，2005

或者由露丝·马兰（Ruth Malan）换一种说法：

如果系统架构和组织架构不一致，则组织架构获胜。

– Ruth Malan，康威定律，2008 年 2 月 13 日

露丝·马兰 (Ruth Malan) 一直擅长以引人入胜的方式制定康威定律：

系统的架构以开发它的团队的形式得到巩固。

如果我们对系统分解进行初步猜测，将子系统分配给团队，然后开始行动，康威定律也会起作用——团队边界将趋向于成为系统内的边界。

– Ruth Malan，康威定律，2008 年 2 月 13 日

这与 Melvin Conway 在其开创性论文中提出的两点有关：

• 一开始：“组织设计团队的行为本身就意味着已经做出了某些设计决策，无论是明确的还是其他的。”
• 最后作为结束语：“系统的初始设计从来都不是最好的。系统可能需要更改。因此，它需要组织的灵活性来有效地设计。” 这反过来又表明了对康威推论的要求，我们将在文章的后面进一步介绍。

其他任何事情都将成为架构英雄的壮举；当建筑英雄必须与由集成时钟的稳定节拍驱动的进度英雄竞争时，这很难实现。

架构需要跨接口发生，这也意味着跨系统/组织接口。这意味着系统架构师（我们称其为架构师）和业务架构师（我们称其为经理）不应该像一个对另一个没有影响一样工作。

– Ruth Malan，康威定律，2008 年 2 月 13 日

这很好地向深入讨论团队接口的团队拓扑眨了眨眼。

关于啤酒和食物，Martin Thompson 和 Pieter Hintjes 提出了以下定义：

康威定律，粗略地指出，组织生产的东西将反映组织的沟通方式。

Martin Tompson 或 Pieter Hintjens，标题中的性别和其他故事，2013 年 12 月 16 日

在同一篇文章中，Pieter Hintjes 继续……

大规模系统是跨越时间和空间的系统。一个大型组织同样跨越时间和空间。康威定律将两者联系在一起。我们的组织方式决定了我们如何集体思考，从而决定了我们集体创造了什么。

– Pieter Hintjes, Sex in Title, and Other Stories , 2013 年 12 月 16 日

再次露丝·马兰说：

我们不仅可以期待我们创建的系统的持续进化，而且可以期待创建它们的组织形式的持续进化。

随着我们创建更多的（自身复杂的）系统，我们可以预期组织形式必须发展以适应系统和组织中更大的系统级挑战。

它们 [系统和组织] 将共同进化，因为如果它们不这样做，康威定律警告我们，组织形式将胜过“跨粒度”到组织扭曲的预期设计。

– Ruth Malan，康威定律，2013 年 12 月 17 日

根据 Michael Nygard 的说法，系统架构是对过去企业决策的考古研究的一个很好的来源，它开启了关于技术和政治的有趣讨论：

您可以在其系统架构中阅读企业政治斗争的历史。

没有最终状态的架构意味着接受“您现在开始的更改将与去年和前一年开始的更改共存。如果你采用这种观点，那么你就不再试图撕毁人行道并做一些全新的事情，你会更多地关注渐进式变化”。这里开始了你的决策历史。

软件，就像所有技术一样，本质上是政治性的。代码不可避免地反映了其创造者的选择、偏见和愿望

J Cascio 

政治起着巨大的作用。它扮演的很多角色都在于它的沉默。但我们不知道沉默的故事。

– Ruth Malan，Conway's Law-ish，2013 年 8 月 5 日

有趣的是，这种关于历史和政治的讨论为逐步增长或增量软件开发如何影响组织奠定了基础。

增量软件开发是基于反馈和学习发展 IT 系统的必要条件。这是我们满足以正确方式支持 IT 系统用户所需的唯一方法：

零碎的增长或渐进式开发不仅是可取的，而且是软件生活中的一个事实。即便如此，我们需要在我们的过程中建立更多的学习。当发现和解决愿景（针对“正确的系统”进行路线修正）和结构（正确构建）问题的成本更低时，更多的学习。

然后，接受我们将继续学习和发展我们的系统，我们需要投资修复错误。增量添加功能是的，但也要修复结构缺陷。这项投资是我们在软件中经常忘记的关键的双重到零碎增长。

当我们继续朝着狂热的“增值”鼓声前进时，我们会陷入这样一种情况：系统有可能在大量推迟的结构性问题下崩溃。

…

从我们以发现为导向的过程的混乱到我们工程系统的精心分解、经过测试的完整性，不应被视为返工或浪费！除非我们在它严重影响用户和我们的业务可行性之后才离开它。那是浪费。

当我们在不确定的迷雾中前进时，熵会增加——并产生更多的迷雾！在不确定的情况下，我们“尝试一下”；接受足够好，然后尝试下一件事情。随着熵的增长，它引入了它自己的不确定性……

– Ruth Malan，康威定律混响，2014 年 5 月 5 日

但是增量软件开发有一个必然的推论。随着软件的增长，熵也在增长。为了包含熵，我们需要重构系统。最后，许多重构导致系统的重大重新设计。增量软件开发需要发展和重新设计组织以适应新系统。这是逆康威机动的结果。我们将在文章末尾回到这一点。与不断发展的系统一起发展组织:

重构是零碎增长的必然结果，允许熵控制。但我们也必须重构组织？如果它会颠覆系统（重新）设计和进化。

…

组织架构（及其通信流程）与系统架构（及其边界和流程）之间存在关系。我们需要考虑到这一点，以获得协同效应，而不是做更难的事情，试图“逆流而上”。

…

跨组织分歧进行整合是一项挑战。当留给快乐的意外时，很可能会有意外的味道，而不是设计——就像，旨在获得更多我们想要的东西，寻找后果，这样我们就可以减少因系统盲目而产生的意外副作用。

– Ruth Malan，康威定律混响，2014 年 5 月 5 日

所有这一切都自然而然地遵循艾伦·凯利的建议：“用系统发展团队。小团队，小系统，零碎成长。从尽可能小的开始，并根据需要增长。不要开始想大。”

根据 Michael Feathers 的说法，当您交付产品时，您就是在交付您的组织。

康威定律——或者“你总是在组织你的组织，所以好好设计你的组织”

- @bjorn_fb，2014年4月24日

再次来自迈克尔：

以胶囊的形式，康威定律意味着如果你有，比如说，三个团队，不管你是否愿意，你最终都会得到三个子系统。

当沟通成本上升时，我们通常会无意识地组织我们的工作以将其最小化。

如果我更容易在我的本地团队中分享愿景和沟通，我们最终会产生一些与其他团队的工作有点分离的凝聚力。

- Michael Feathers，推特，Reddit 和康威定律，2017 年

最后，我在 Dan Slimmon 的幻灯片Conway's Law: The Skeleton of DevOps 中找到了 Adam Jacob 的这个（我们假设是 Chef 的）。

您的组织结构没有解决您的问题。

这是你以前如何解决它的神器。

– 亚当雅各布

这又是逆康威机动的一种表达方式。

这似乎流入了 Mel Conway 的观察：

[康威定律] 的重要性……并不是你的设计组织决定了你可以设计的东西。

原则的重要性……是……您的设计组织阻止您设计一些您可能应该构建的东西。

该原则创建了一个必要性 (1) 不断问：“有没有更好的设计，因为我们的组织而无法提供给我们？” (2) 如果找到更好的设计，对改变组织持开放态度。

– Mel Conway，在多门课程中简化应用程序开发，2016 年

要改变组织，你需要康威的推论：

然后就是我所说的康威推论：

“组织灵活性对有效设计很重要”。

IMO 这是他文章中最深刻的部分。

- @jeffsussna，2021年5月9日

没有组织的灵活性，正如 Ruth Malan 所说，“ [当] 系统架构和组织架构不一致时，组织就会获胜”。

组织将始终限于生产与组织的真实、实地沟通结构相匹配的设计。请注意，真正的地面通信结构不一定是传统组织结构图上描述的结构。人们不会将他们的交流仅限于组织结构图上的线条。团队会联系他们所依赖的任何人来完成他们的工作。再次来自团队拓扑的团队接口。

这将我们优雅地带到逆康威机动：

…组织应该发展他们的团队和组织结构以实现所需的架构。目标是让您的架构支持团队完成工作的能力——从设计到部署——而不需要团队之间的高带宽通信。

– Nicole Forsgren，博士，Jez Humble 和 Gene Kim，Accelerate，2018 年

因此，在组织团队之前，我们需要了解需要什么软件架构。

团队分配是架构的初稿。

迈克尔·尼加德， 2007

这意味着任何对工程团队的组成和位置做出决策的人都会强烈影响系统架构。我们又来了露丝·马兰。

康威定律的另一个含义是，如果我们让经理决定团队，并决定将构建哪些服务，由哪些团队决定，我们就隐含地让经理决定系统架构。

– Ruth Malan，康威定律，2008 年 2 月 13 日

因此，组织设计和软件设计是沟通的载体，两者都需要由同一群知情人士（即经理和架构师）来处理：

最终，架构的很大一部分与技术或解决方案细节无关。这是关于建立正确的结构、工作方式、沟通渠道和整体条件

- @himal，2021 5月3日，

我更相信自称是架构师的人需要技术和社交技能，他们需要了解人并在社交框架内工作。他们还需要一个比纯技术更广泛的职权范围——他们需要在组织结构和人事问题上有发言权，即他们也需要成为一名经理。

Allan Kelly，回到康威定律，2006 年 1 月 6 日

当我想到我认识的真正优秀的技术人员时……他们迟早都会意识到解决技术问题需要他们在技术领域之外工作。

艾伦·凯利，回归康威定律，2006

我在这方面有不同的经历。理解它的领导支持我进行必要的结构性变革。不理解的领导……我很快就遇到了问题。

“你为什么要入侵我的组织？你不是技术人员吗？留在你的车道上”

- @himal，2021 5月3日，

好吧，一开始只是总结了不同人将康威定律阐明为我自己的一种笔记的各种方式，变成了思想、观察和整个组合之间联系的交叉参考。这篇文章似乎成为了永无止境的作品。