专栏首页DDD康威定律与逆康威定律

康威定律与逆康威定律

康威定律随着微服务架构兴起的步伐慢慢复苏,重新进入人们的视线,但他的威力远远不仅限于简单的指导如何拆分微服务,不管是整个团队的战力,还是架构方案能否顺利落地都起着重要的作用。

康威定律

先回顾一下什么是康威定律:1968年,计算机系统研究院的梅尔康威在Datamation杂志上发表了一篇论文How Do Committees Invent?

这篇论文中有一句话被总结为康威定律:“设计系统的组织由于受到约束,这些设计往往是组织内部沟通结构的副本。”

下面先通过一次切身经历来阐述定律如何发挥威力,以及如何通过逆康威定律得到我们想要的架构方案

起初我带领一支团队负责一个业务,先称它为APP1,经过一段时间,老板找我谈话,说:“APP1在你的带领下,运行得不错,应该承担更大的责任,后面APP2团队也由你负责”。

经过一段时间的迭代,APP2需要一个配置服务,支撑差异化运营

APP2架构师根据最新业务需求,提出了给APP2增加一个配置服务,对于APP2来讲,架构师都无需赘述,此架构方案无疑是合理的

但从整体看APP1已经有配置服务

此时就有了两个方案:

1.按架构师规划,APP2构建新的配置服务2.增强APP1的配置服务,让它同时支撑APP1和APP2

怎么决择呢?

从架构角度,方案一似乎更有优势,独立,两个APP之间也不会相互干扰,原先的配置服务也无需改动,相对去改造一个旧系统,构建新系统负担还小一些

但从组织结构讲,组织效能角度也更高效,大局出发,也不需要两个相似的配置服务,组织结构与架构结构也更有同态性

此时,康威定律就发挥了至关重要的作用:“如果系统的架构和组织结构不一致,那么组织结构将成为赢家”


当我在计划着进一步整合两个团队时,事情发生了变化,老板又找我谈话了,“经过这段时间,发现你带两个团队有些吃力,这样吧,以后你就只负责APP2团队”

随着业务的继续开展,发现了个问题,当APP2团队需求需要变更配置服务时,为难了

APP1使用配置服务深度和广度都高于APP2,所以在划分时,配置服务归于APP1了,之前都是同一个大团队,资源协调很简单,内部沟通很容易

此时怎么办?

原先团队内部的沟通,需要跨团队沟通了,再简单的一次变更,都需要提前沟通,协调排期,制约了高效迭代交付能力

所以APP2团队不得不剥离APP1的配置服务,另起炉灶,回到当初架构师的方案一

这其实还是康威定律发挥着威力:组织内部的沟通路径(无论是否和正式汇报线一致)严重制约了组织所能设计的解决方案的类型

逆康威定律

这是ThoughtWorks技术总监James Lewis突发奇想地提出的,组织要根据他们想得到的软件架构来设计团队结构,而不是期望团队盲从一个被设计好的团队结构

其核心观点在于,将软件架构看作一个独立的概念,认为它可以被孤立设计,然后交由任何团队来实现,这从根本上就是错误的

我们把上面的示例,顺序倒置过来,就是逆康威定律。

我详细阐述下:

刚开始,APP1和APP2是两个独立完整的团队,都有各自的配置服务,也就是

虽然他们功能相似,但由于在两个团队里面,与组织结构和沟通路径都是匹配的

从公司全局架构看,发现配置服务只需要一个就够了,推倒烟囱式架构,整合资源,配置服务中台化,这也是近些年各公司崇拜的中台文化

怎么办呢?简单啊,提取共性,抽象整合呗。

现实没那么轻松,如果两大APP团队,是支撑公司盈利的两大业务,营收压力也很大,基本上整合是句空话,看看有多少公司的BU都是各自为战,烟囱式系统一个比一个强悍,谁能动得了?

此时怎么办?整合组织结构,让两个团队组合成更大的团队,拥有独立的架构团队,团队内部自己就会催生出整合的力量

再看一个示例,假设有四个独立团队,每个都由前后端开发工程师组成,他们分别负责系统的不同部分,然后对DBA提出数据库变更请求。

如果这四支团队独立的前端和后端开工程师推动了UI和应用层的前后端分离,而有一个共享的DBA团队,那么很可能会带来这样一个单一的共享数据库。

因为康威定律的同态力会强烈地牵引软件架构“自然而然”地体现出当前的组织设计和沟通路径。

当我们在使用微服务架构时,每个独立服务都需要有属于自己的数据存储。

通过应用逆康威定律,可以在各个独立的客户端应用和API开发团队里面增加一名数据库开发人员,那架构结构自然就体现出来了。

总结

想想架构风格千千万万,为什么分层架构却是最流行的,也是最容易实践成功的,因为有独立的前端团队,后端团队,基础服务团队,对于业务数据流向,正好也是从UI发起,逻辑层处理,数据库存储,组织结构与架构结构是匹配的。这就是康威定律的威力。

组织结构和团队间真实的沟通路径会直接影响所构建系统的架构。如果有四个小组合作开发一个编译器,那么你将得到一款具有四个步骤的编辑器。对于一家软件产品公司来说,组织结构预示着产品架构。

过去很多组织结构调整的潜在目标都是为了减少员工或者围绕管理者和领导者的权势建立山头。可对于一家软件公司,势必慎重,必须要考虑架构,更可以应用逆康威定律:设计团队满足理想的软件架构

简而言之,在设计软件架构或进行组织结构调整时,将康威定律纳入考虑因素之中,就能够受益于兼顾软件架构和团队设计的同态力。

本文分享自微信公众号 - 码农戏码(coder-game),作者:朱先生

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-10-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 康威定律对架构设计的指导意义

    动物界有个非常有趣的现象,群居性动物,为了保证群体的稳定性,都有两个比较有意思的特征就是等级和分工,而等级和分工最终会演化成类似金字塔形式的结构,这种结构就是组...

    亦山
  • 微服务的灾难(6) -- 康威定律和 KPI 冲突

    这里的 'are constrained to' 即是该定律的精髓所在。如果一个公司的组织架构已经基本成型了,那么基本上设计出的系统架构和其人员组织架构必然是一...

    iTesting
  • 程序员N定律和N原则---康威定律在实践中的一点思考

    以前我们或多或少都听说过一些定律,比如木桶定律、墨菲定律、摩尔定律、鲇鱼效应、多米诺骨牌效应、马太效应等等等等。在软件工程领域中,也有适用软件开发和组织管理的经...

    别打名名
  • 康威定律对气象软件开发有多大作用?

    Any organization that designs a system will produce a design whose structure is ...

    用户1247399
  • 康威定律,作为架构师还不会灵活运用?

    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ...

    程序新视界
  • 微服务拆分到什么粒度合适——康威定律

    微服务这个概念一直很火,现在ServiceMesh概念更火,最近我经手的多个项目也都采用微服务的方式开发。但实践发现,当一个RD同时开发超过2个微服务的时候,出...

    普通程序员
  • 《微服务设计》第 10 章 康威定律和系统设计

    yeedomliu
  • 一文一点 | 康威定律和单一职责原则的关系

    康威定律是在1968年由Melvin Conway提出来的,并且以他的名字命名,基本意思呢,是这样的。

    王新栋
  • 思特沃克发布最新一期《技术雷达》,指出“康威定律”在当今数字时代依然适用

    今年是全球软件及技术咨询公司思特沃克(Thoughtworks)每半年发布一期《技术雷达》报告的第 11 个年头,本次报告突出了平台产业的低迷

    ThoughtWorks
  • 美众议院提案禁止政府采购中企视频监控设备,海康威视回应

    新智元
  • 12 张手绘图,我搞懂了微服务架构

    来源:tengshe789 juejin.im/post/5c0ba2bef265da614d08fefe

    芋道源码
  • 站在更高的角度,看微服务架构的理论基础

    微服务是近些年非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 。前段时间看了Mike Amund...

    李红
  • 论微服务拆分

    使用微服务架构模式的思想对目标系统进行拆分之前,我们需要先明白服务拆分起点和终点,以及需要考虑的因素与坚持的原则。所谓起点就是需要清楚拆分的是已有的项目还是新的...

    端碗吹水
  • Springcloud(二)-拆分微服务(慕课网廖师兄SpringCloud微服务实战)

    Organizations which design Systems are constrained to produce design which are c...

    Meet相识
  • 软件开发中有趣的规律

    说到软件工程很多人会想到瀑布模型、敏捷开发、领域驱动。虽然这些名词大家耳熟能详,但如果你去听大牛们的讲座或者查阅相关资料会发现每个人陈述的都不大一样。这让听的人...

    sibenx
  • 放弃微服务,我们为什么重回单体架构?

    InVision 公司的技术架构经历了从微服务合并回单体架构的过程,本文具体分析了这种架构迁移的技术原因和组织原因。

    深度学习与Python
  • 我们公司放弃了微服务,重回单体架构

    每当我们将 InVision 的一个微服务合并回单体的时候,我都会发一条庆祝的推文。在这些推文中,我都喜欢包含一张关于灭霸的动图,这张动图就是灭霸将最后一颗无限...

    芋道源码
  • 架构学习之路——高可用高并发系统设计原则

    墨菲定律 - 任何事没有表面看起来那么简单 - 所有的事都会比预计的时间长 - 可能出错的事情总会出错 - 担心某种事情发生,那么它就更有可能发生

    博文视点Broadview
  • 针对华为、海康等5家中国高科技企业,美国拟颁布产品合作新禁令,8月生效

    据路透社报道,一位美国官员表示,特朗普政府计划本周敲定监管规则,将禁止美国政府从使用5家中国高科技企业产品的公司购买商品或服务,这5家中国企业包括华为、海康威视...

    新智元

扫码关注云+社区

领取腾讯云代金券