首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >康威定律对架构设计的指导意义

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

作者头像
亦山
发布于 2021-06-09 14:48:06
发布于 2021-06-09 14:48:06
2.6K0
举报

什么是康威定律?

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.– Melvin Conway(1967) 设计系统的架构受制于产生这些设计的组织的沟通结构。

组织设计背后的生产关系逻辑

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

如在蚂蚁世界,会有如下分工,职能和边界清晰

  • 蚁后(具有受精和生殖能力的雌性蚂蚁,承载着繁衍工作)
  • 雄蚁 雄蚁是蚁群中唯一的雄性蚂蚁。完成交配后不久即死亡。
  • 工蚁 是不发育的雌性,一般为群体中最小的个体,但数量最多

再如大到人类历朝历代的中枢机构,秦朝的三公九卿制、隋朝的三省六部制、宋朝的二府三司制、元朝的行省制度,元朝的中书省制,甚至现在的人们代表大会制度,小到家庭成员的构成,无不体现着群体性动物的特征:等级和分工。

组织架构的设计,本质上有了两个层面的含义:

  • 是生产力和生产关系的体现。按照这种设计会产生最大化的效益产出。当一个企业的生产力跟不上生产关系时,组织上会做出相应的调整,比如某一个业务部门因为整体业务不好(生产力不足),企业经营者会砍掉这个业务部门。
  • 是代表的时企业的运作方式和沟通关系。一个组织架构的设计分为节点和线组成,节点表示的生产力,而连线,表示的生产关系,而生产关系又可以做一些细分,从重要程度上,可以简单的概括为:汇报关系、业务合作关系、协同关系。在运作的过程中,实际反映的是人与人的沟通关系。

上面的论述可能有点抽象,可以看下现实的例子:以典型的几个互联网公司的组织架构上来看,透过组织结构,就可以了解到一个公司的沟通方式,甚至基于组织架构的设计,还能透出其企业的崇尚某种文化。

从逻辑上,会有如下的关系:

组织结构决定软件系统结构

组织结构确立了,相当于生产关系确立,对应的沟通方式也就确定了。

如下图所示,是一个一般的简单大的公司运作模式:采购部门像供货商采购商品,然后将采购的商品给销售部门进行销售;而账务部门需要将采购部门的采购单和销售部门的销售单进行对账。

假设你是这个公司的CIO负责这个公司的信息化,来满足各个部门的日常工作,那么会很自然地设计出如下几个系统:

综上所述, 软件系统实际上只是通过信息化的方式,来完成企业的组织结构内的成员的既有的沟通协作模式。

这种本质,就是马尔文·康威在1967年提出的《康威定律》:

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.– Melvin Conway(1967) 设计系统的架构受制于产生这些设计的组织的沟通结构。

康威定律的解读

基于康威定律的定义,可以从下面四个层面来看:

第一定律

Communication dictates design。 组织沟通方式决定系统设计。

经验一:为什么组织设计要追求小团队?

根据上一章节的例子可以看出,现实中组织结构中的沟通方式是怎样的,通过信息化的方式实现的系统就是怎样的。 如果组织结构中的沟通过程很复杂,沟通的成本很高,那么,相应的系统间的交互也就变得异常复杂; 而对于软件系统而言,当复杂度超过一定范围时,就会变得不可维护,导致系统瓶颈无法支持业务。

《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律:沟通成本 = n(n-1)/2。举例说明一下:

  • 5人项目组,需要沟通的渠道是 5*(5–1)/2 = 10
  • 15人项目组,需要沟通的渠道是15*(15–1)/2 = 105
  • 50人项目组,需要沟通的渠道是50*(50–1)/2 = 1,225
  • 150人项目组,需要沟通的渠道是150*(150–1)/2 = 11,175

所以在组织设计上,应当追求小团队,一是沟通成本低,二是背后的软件系统的复杂度低。这也是为什么互联网公司都追求小团队的原因之一。沟通的问题会带来系统设计的问题,进而影响整个系统的开发效率和最终产品结果。

经验二:微服务架构模块划分要充分考虑团队人员结构

微服务架构的拆分实践上一个很大的误区,就是纯粹根据领域依赖关系直接拆分 而忽略的团队的人员构成。

举一个例子:假设一个研发团队要做一个营销平台系统,架构师觉得微服务比较流行,然后尝试进行微服务拆分,所以根据领域关系,拆分了六个微服务模块,然而研发团队只有3名成员,按照这样的设计,每个成员要维护 2 个微服务,如果要做一个简单的功能,一个成员需要到两个微服务上开发,让微服务开放出 RPC接口,然后在BFF中做能力整合。这种开发行为本身就是不正确的。 另外,微服务的拆分,还会导致分布式事务等其他的问题,在本来研发资源就不充足的情况下,增加了大量的额外成本,最终影响交付质量。 如果业务发展比较好,公司有足够的资金来壮大团队,比如按照微服务设计每个微服务模块投入 10名研发人员(共 10 * 6 = 60) 的研发规模,那这个架构设计我认为至少是合理的;但是如果公司投入有限,总共只能投入非常有限(如10人内)的资源,我的建议是尽可能不要使用微服务架构,或者减少微服务的模块数量。

所以:微服务的拆分,要确保有足够的研发组织保障为前提,结合领域依赖和业务特性为原则。

第二定律

There is never enough time to do something right, but there is always enough time to do it over。 时间再多一件事情也不可能做的完美,但总有时间做完一件事情。

软件系统的形成,分为两阶段:首先人类对现实世界的某个领域的运作方式的理解和认知,第二个阶段是基于理解和认知由开发人员进一步抽象然后实现。而无论哪个阶段,都不可能做不到完美。 事物本身在不断发生改变,人类也会在不同的阶段有不同的认知,所以: 不要想着花大量的时间设想着可以设计一套自认为可以完美支持某个领域内所有场景的系统。而是着眼于眼前的业务域问题,解决好,支持好。

没有完美的系统,只有不断完善和演化的系统。

  • 人手永远是不够的,事情永远是做不完的,但可以一件一件来。这不就是软件行业中“敏捷开发”模式所解决的问题吗。面对这样的状况,敏捷开发可以做到不断迭代、持续交付、快速验证和反馈,并持续改进。
  • 再牛的开发也会写出bug,再全面的测试覆盖率也无法测出所有的问题。解决方案不是消灭这些问题,是容忍一些问题的存在,然后通过适当的设计(冗余、监控、高可用设计)当问题发生时能够快速解决。 好的架构不是买来的,也不是设计出来的,而是根据业务落地生根长期演化来的。
第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization。 线型系统和线型组织架构间有潜在的异质同态特性。

首先解释下 “异质同态”: 虽然不是同一个事物,但是他们的形态(如之间的逻辑关系,构成)保持一致。

这个特性其实和康威定律的定义项对应。如上面举例,业务部门的构成,决定了对应的业务系统,而业务部门之间的沟通方式,决定了业务系统之间的接口设计。

在软件系统设计的时候,要充分考虑组织和系统之间的异质同态性。

第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。 大的系统组织总是比小系统更倾向于分解。

组织的沟通成本,随着成员数量的增加而指数级增加。为了降低复杂度,会出现各种组织趋于分解的设计,如金字塔的分层模型,以控制每一个节点的关联的数量。而对应地,软件系统也会根据这一趋势,甚至是软件系统会随着组织结构的复杂度过高,而导致系统无法继续维护。 所以,无论是从组织设计上,还是软件架构设计上,都是大系统比小系统更趋于分解。

分解是应对复杂度的基本解决之道。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021/06/01 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
康威定律对于系统架构很重要吗?
康威定律对系统架构很重要吗? 背景 在了解了微服务,敏捷开发还有我们现在的组织架构,是不是之间存在一定的关联。比如A团队负责a服务,B团队服务b服务,然后整个部门之间的微服务串起来就形成了一个大的服务
袁新栋-jeff.yuan
2022/09/19
6320
康威定律对于系统架构很重要吗?
康威定律对气象软件开发有多大作用?
IT行业有个大名鼎鼎的Conway’s Law(康威定律),在气象软件开发中这个康威定律究竟发挥多大作用呢?气象行业虽然和IT行业有很大不同,但气象的现代化离不开IT,也离不开越来越智能的数字化技术。今天想跟大家聊聊关于康威定律的话题。 Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.—Con
用户1247399
2020/08/05
6270
康威定律对气象软件开发有多大作用?
康威定律,作为架构师还不会灵活运用?
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
程序新视界
2019/10/22
8140
康威定律,作为架构师还不会灵活运用?
程序员N定律和N原则---康威定律在实践中的一点思考
以前我们或多或少都听说过一些定律,比如木桶定律、墨菲定律、摩尔定律、鲇鱼效应、多米诺骨牌效应、马太效应等等等等。在软件工程领域中,也有适用软件开发和组织管理的经典定律和原则,这些经典的定律和原则被程序员上传到了代码托管平台Github 上,并且被翻译成了多国语言版本,中文版可见https://github.com/nusr/hacker-laws-zh。这里罗列一下:
别打名名
2020/05/09
1.4K0
程序员N定律和N原则---康威定律在实践中的一点思考
微服务拆分到什么粒度合适——康威定律
微服务这个概念一直很火,现在ServiceMesh概念更火,最近我经手的多个项目也都采用微服务的方式开发。但实践发现,当一个RD同时开发超过2个微服务的时候,出现bug或故障的概率会提升。
普通程序员
2019/10/23
1.3K0
微服务拆分到什么粒度合适——康威定律
康威定律与逆康威定律
康威定律随着微服务架构兴起的步伐慢慢复苏,重新进入人们的视线,但他的威力远远不仅限于简单的指导如何拆分微服务,不管是整个团队的战力,还是架构方案能否顺利落地都起着重要的作用。
码农戏码
2021/10/21
4.9K0
微服务的灾难(6) -- 康威定律和 KPI 冲突
这里的 'are constrained to' 即是该定律的精髓所在。如果一个公司的组织架构已经基本成型了,那么基本上设计出的系统架构和其人员组织架构必然是一致的。
iTesting
2019/10/29
7590
站在更高的角度,看微服务架构的理论基础
微服务是近些年非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容。
李红
2020/01/14
1.2K0
站在更高的角度,看微服务架构的理论基础
论微服务拆分
使用微服务架构模式的思想对目标系统进行拆分之前,我们需要先明白服务拆分起点和终点,以及需要考虑的因素与坚持的原则。所谓起点就是需要清楚拆分的是已有的项目还是新的项目,如果是已有的项目,那么这个项目处于什么样的架构阶段。而终点则是服务拆分后所需达到的架构阶段,以及后续扩展性的考虑,毕竟好的架构不是一次性设计出来的,而是不断进化来的。
端碗吹水
2020/09/24
4110
你真不敢说精通微服务架构深度解析:微服务采用前提康威定律吗?
根据康威定律,技术架构与组织的职责划分相关,而职责划分从根本上确立了组织的沟通协作方式,这种协作方式最终决定了技术架构的形态。如果你的组织本身是比较松散的协作方式,往往你的架构会变得离散;而如果你的组织是紧耦合的,架构往往也会慢慢向紧耦合的方式发展。
愿天堂没有BUG
2022/10/28
3240
你真不敢说精通微服务架构深度解析:微服务采用前提康威定律吗?
《微服务设计》第 10 章 康威定律和系统设计
第 10 章 康威定律和系统设计 梅尔 · 康威于 1968 年 4 月 在 Datamation 杂志上发表了一篇名为“How Do Committees Invent”的论文,文中指出:任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。这句话被称为康威定律 ---- 10.1 证据 ---- 10.1.1 松耦合组织和紧耦合组织 在 Exploring the Duality Between Product and Organizational Arch
yeedomliu
2019/09/30
5280
《微服务设计》第 10 章 康威定律和系统设计
架构师必须掌握的架构设计原则
来自 Craig Larman 的软件设计书《UML 和模式应用》,Larman 在书中提出软件设计的关键任务是职责分配,并提炼总结出 9 种 (5 种核心 +4 种扩展) 软件职责分配模式,这些模式是比 GoF 设计模式更抽象的元模式。
架构狂人
2023/08/16
4320
架构师必须掌握的架构设计原则
架构师必须知道的架构设计原则
一晃我在软件研发行业工作十多个年头了,前面大部分时间做架构设计和开发,现在转型做研发管理。随着时间的推移,很多技战术细节性的东西 (工具,框架,编程语言) 在我脑海中渐渐模糊,但是一些平时学习积累起来,并且在实践中加深体会的软件架构设计和组织原则,这些原则性的东西却丝毫没有被时间冲淡,反而愈加清新。现在即使我不在一线开发,但这些沉淀下来的原则仍然潜移默化地影响我的日常管理和部分架构设计指导工作。我想有必要总结一下那些业界知名,给我留下深刻印象的软件架构设计和组织原则,和大家一起分享。1软件设计原则GRASP 通用职责分配软件模式
Java架构师必看
2020/08/17
1.2K0
图解:在资深架构师眼中的架构应该是怎样的?
大概在7~8年前,我曾经有一个美国对口的架构师导师,他对我讲架构其实是发现利益相关者(stakeholder),然后解决他们的关注点(concerns),后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》,里面提到的理念也是这样说:系统架构的目标是解决利益相关者的关注点。
技术zhai
2018/05/18
1.1K0
康威定律:AI 时代的 IT 组织变革
据调查报告(见文末链接),在 GitHub Copilot 发布的头 6 个月,在美国的开发人员有 92%拥抱采用了它或者同类生成式 AI 工具进行编码开发。可见码农天然的人皆有“偷懒”之心 - 如果更快、更高质量的炮制出一些代码,少掉几根头发,有什么不好呢?
海岛船长加西亚
2024/01/10
4030
康威定律:AI 时代的 IT 组织变革
【从零开始学微服务】04.微服务架构的特点
当我们谈到组件的时候,一般是指可以独立替换、可以独立升级的功能单元。在以往的架构中,我们引入组件时,使用动态链接库或jar包,甚至是一组代码。在微服务架构中,是把服务作为了组件,使用轻量级的HTTP进行远程调用。
万猫学社
2022/12/01
3560
【从零开始学微服务】04.微服务架构的特点
业务建模:系统边界与规则
Organization which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
小诚信驿站
2022/05/28
3.9K0
业务建模:系统边界与规则
微服务是传统企业电商解决方案的银弹吗?
近几年,微服务成为最流行的技术名词之一,尤其受到亚马逊、阿里等电商巨头的影响,很多传统企业在实施电商过程中也纷纷往微服务架构靠拢,相比单体架构,微服务确实有很多优点,就像 Sam Newman 在“Building Microservices”[1] 中所阐述的那样:
美的让人心动
2018/06/04
6470
微服务的灾难
只发了一部分(另外一部分出于言辞激烈或影射太容易对号入座等原因没有发),最近又看到有老外写类似的东西,阅读后主要是说基础设施和稳定性的,和我当时发出来的六篇正好算是互补吧。
梦醒人间
2021/06/17
5190
微服务并不能修复你破碎的组织文化
我们常常关注技术中的设计模式,而忽略了我们社会结构中也存在类似的模式。通过审视我们与别人的沟通,可以找到许多技术性问题的解决方案。让我们来谈谈当你和讨厌的人类沟通时,你需要知道的五件事。
用户9624935
2022/04/02
3740
微服务并不能修复你破碎的组织文化
推荐阅读
相关推荐
康威定律对于系统架构很重要吗?
更多 >
LV.0
江苏欧飞电子商务有限公司不是CXO
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档