康威定律对于系统架构很重要吗?

Posted 2022-10-19 袁新栋-jeff.yuan

康威定律对系统架构很重要吗?

背景

在了解了微服务，敏捷开发还有我们现在的组织架构，是不是之间存在一定的关联。比如A团队负责a服务，B团队服务b服务，然后整个部门之间的微服务串起来就形成了一个大的服务系统。那为什么要这样安排呢?

*organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway
设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构

康威定律可是比微服务早出来半个世纪,康威定律也许就是微服务系统设计的第一性原理。接下来我们了解一下康威定律的内容。

康威定律详细介绍

著名学者对康威定律的解读

我们先看看各位大佬是如何解读的，一千万个人心中有一千万个哈姆雷特。随着大环境的变更，大家对一一件事情的理解和认知也会有所改变，也许会曲解原作者的意思（产生争议），也许会在原作者的意思上再升华一个层次。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. 艾伦·凯利的推论：

组织设计就是系统设计。

——艾伦·凯利，2005

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

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

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

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

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

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

11. 组织生产的东西将反映组织的沟通方式。

12. *以胶囊的形式，康威定律意味着如果你有，比如说，三个团队，不管你是否愿意，你最终都会得到三个子系统。
    当沟通成本上升时，我们通常会无意识地组织我们的工作以将其最小化。
    如果我更容易在我的本地团队中分享愿景和沟通，我们最终会产生一些与其他团队的工作有点分离的凝聚力。
    *

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

13. 团队分配是架构的初稿。

迈克尔·尼加德， 2007

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

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

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

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

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

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

个人经历和对康威定律的理解

1. 从上文看得出，康威定律讲了团队组织和系统架构之间的影响，但是通过我个人的经理来讲。看到的的确是这样。
2. 首先在我的第一家公司，是按照业务线和负责的服务进行团队分工的。地产线，金融线，医疗线等等。还有一些通用产品线(也就是我当时所在的产品线)，中台部门 ，基础架构部门.如下图。

3. 通过上面的组织架构图我们先判断一下整个公司的架构。

   1. 基础架构组，提供基础服务， 包括一些消息中间件，服务基础框架等，
   2. 中台底下中台产品线 提供公司核心的模块化服务 ，通用产品线和中台产品线重合是只不过是通用产品线是中台服务的老版本，未做拆分的服务。
   3. 业务产线，针对中台服务提供的基础服务进行定制化开发，提供服务给用户。

4. 是的，确实是从组织的架构图可以看出我们的系统架构之间的交互逻辑。也就像康威定律所讲:组织设计就是系统设计。

5. 我当时所在的业务线是处在通用产品线，给我最大的感觉就是，这条线不安全，可能被优化掉，作为开发着的我很没有安全感（并且我只是维护老产品，不负责新的迁移），在架构设计中，还有一个叫马斯洛定理的东东没有给开发人员足够的安全感，导致我对迁移中台这件事情很反感。以至于我不去配合甚至去做一些"保护老系统"的做法。由于多个像我这样的人存在导致服务下沉的节奏很慢，最后在我离职的时候还是没有迁移成功的。这也就是符合了康威定理中的： 如果系统架构和组织架构不一致，则组织架构获胜，我个人认为架构方向发展被阻碍，那就是组织获胜了。也就是通用产品线获胜，被干掉的节奏很慢了。

6. 我们在开发的过程中，经常是不是调用别人服务？ 这还不如我自己写呢。对于大多程序员来讲，写代码相对于跨团队沟通更容易，并且经验稍加欠缺的程序员就那样干了。到最后同一个逻辑在ABCD服务都存在了，产品说需要改一下这个逻辑，于是a团队忘了改了，导致了线上事故。突然想到了一句话： 多数人为了逃避真正的思考愿意做任何事情。 是的夸团队问题貌似在任何一家公司都存在，那解决方案必然是将联系亲密的团队划分在一起，或者归属于同一个leader。这样的架构设计由于组织架构的调整就得到了巩固。可以看的出 系统的架构以开发它的团队的形式得到巩固。

总结

1. 康威定律也许就是微服务架构的第一性原理之一，遵循它可以让我们的系统架构和组织架构变的合理，更加稳定。让我们的开发人员效率更高。
2. 上面我们通过著名学者和我个人的一些经历，认识了一下康威定律。在总结下，那就是组织架构和系统架构之间是相互影响的，正确的做法是通过系统架构来设置组织架构，因为组织架构会战胜系统架构。
3. 马斯洛定理也是系统设计中占有很重要地位，从某一个角度来讲，这其实也是包含于组织架构之中的，也就是说组织架构人员的设定可以根据马斯洛定理来进行。
4. 康威定律对系统架构很重要！！！！！

个人的一些理解和拙见，希望大佬们能指正！！

引用

1. https://www.jdon.com/56768

2. http://icyfenix.cn/architecture/architect-history/microservices.html