康威定律对架构设计的指导意义
什么是康威定律?
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。
大的系统组织总是比小系统更倾向于分解。
组织的沟通成本,随着成员数量的增加而指数级增加。为了降低复杂度,会出现各种组织趋于分解的设计,如金字塔的分层模型,以控制每一个节点的关联的数量。而对应地,软件系统也会根据这一趋势,甚至是软件系统会随着组织结构的复杂度过高,而导致系统无法继续维护。
所以,无论是从组织设计上,还是软件架构设计上,都是大系统比小系统更趋于分解。
分解是应对复杂度的基本解决之道。
康威定律对架构设计的指导意义相关推荐
- Web信息架构——设计大型网站(第3版)
Web信息架构--设计大型网站(第3版)(久负盛名经典再现,信息架构设计领域基石之作!) [美]]Peter Morville(彼得·莫维尔) Louis Rosenfeld(路易斯·罗森菲尔德) ...
- Web信息架构——设计大型网站(第3版)(久负盛名经典再现,信息架构设计领域基石之作!)
Web信息架构--设计大型网站(第3版)(久负盛名经典再现,信息架构设计领域基石之作!) [美]]Peter Morville(彼得·莫维尔) Louis Rosenfeld(路易斯·罗森菲尔德) ...
- Web信息架构——设计大型网站(第3版)(久负盛名经典再现,信息架构设计领域基石之作!)...
Web信息架构--设计大型网站(第3版)(久负盛名经典再现,信息架构设计领域基石之作!) [美]]Peter Morville(彼得·莫维尔) Louis Rosenfeld(路易斯·罗森菲尔德) ...
- 康威定律,作为架构师还不会灵活运用?
Soft skills are always hard than hard skills. 软技能比硬技能难. 老板听说最近流行"微服务",问架构师咱们的系统要不要来一套?老板又听 ...
- 每个架构师都应该了解的理论:康威定律
点击蓝色"程序猿DD"关注我 回复"资源"获取独家整理的学习资料! 作者 | 丑胖侠二师兄 来源 | 公众号「程序新视界」 老板听说最近流行"微服务& ...
- SOA架构设计经验分享—架构、职责、数据一致性
1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRAS ...
- SOA架构设计(转发)
阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DD ...
- 架构设计入门知识【转载】
首先,本文不是想介绍架构设计一步一步如何做,细节的技术手段,完整的理论框架这些问题.这些问题在一次演讲中也不可能覆盖.本演讲更多时候是想给很多从细节设计中走过来,对什么是架构设计只有过一些模糊的,不成 ...
- 分布式锁选型背后的架构设计思维【附源码】
1. 分布式锁本质 提到分布式锁,有很多实现,比如Redis分布式锁.ZooKeeper分布式锁.etcd分布式锁等.但是选择哪个更适合你的项目?在<基于CAP模型设计企业级真正高可用的分布式锁 ...
最新文章
- linux中iptables入门教程--设置静态防火墙
- DSP320C6000的指令列表汇集
- Arduino可穿戴教程ArduinoIDE新建编辑源文件
- LPS25HB 气压计 资料整理
- MyEclipse9安装Checkstyle5.5插件(图解)
- 【Java】Socket实现的C/S模式半UI多人聊天程序
- 十项全能的java大神
- java中nodelist的用法_我可以在Java中使用for-each遍历一个NodeList吗?
- 喷水装置2(nyoj12)
- mogodb集群配置笔记
- 黑马程序员--java基础知识注意点收录
- 计算机读不出光盘,光驱读不出光盘,小编教你电脑光盘不能被识别怎么解决
- nginx重启后出现[error] open() “/usr/local/var/run/nginx/nginx.pid” failed
- jsonp跨域原理(简单粗暴)
- C/C++试题集——字符串篇
- 从零开始做运营第一课:运营是做什么的?一篇文章解释清楚!
- java中级课程_完整的JAVA中级程序员全面学习路线教程
- RabbitMQ-Plugin configuration unchanged.
- 推荐四个在线任务管理网站
- document.referrer和history.go(-1)退回上一页区别
热门文章
- Crazy Number---3755
- 狂野飙车8服务器在哪个文件夹,狂野飙车8数据包安装存放位置详解
- POI实现EXCEL导出(resources配置路径下或者网络图片)
- T 基础 高数 上:函数
- 300套PPT模板+实习僧20套精选简历+其他各种素材PPT模板(免费分享)
- 最后期限Lite,兴趣社区圈子论坛小程序前后端
- 双鱼座男适合学计算机专业,双鱼座男生适合的职业
- Vue.use 写多个_老师说“你女儿跟多个男生早恋”,爸爸的回应改变了女儿的一生|早恋|马伊琍|晓敏|老师|告白...
- 软件研发落地实践,要从设计就开始
- 检测到目标站点存在javascript框架库漏洞