架构反思-01-康威定律
架构反思-01-康威定律
从开发逐步转到做系统设计已经有挺长一段时间了，在这个过程中有向别人学习的东西，有从好的书上学到的东西，有自己摸索的一点经验，抽点时间整理下，也反思在系统设计上的问题。
把康威定律作为第一条，是因为实际上是从康威定律开始才去思考系统元素结构问题，慢慢地开始有意识去反思业务、组织、技术这个铁三角的关系。
康威定律是很早已经提出来的架构和组织上的关系现象，这个现象在《人月神话》中被提及后，受到广泛关注。康威定律总结为4条，一般最受大家重视的第一条：
- 组织的沟通结构通过系统设计表达出来
- 时间再多也无法把事情做完美（right），但总有时间把事情做完（over）
- 线型系统和线型组织架构间有潜在的异质同态特性
- 大的系统组织总是比小系统更倾向于分解
沟通结构
从另外一个角度看的话，软件的开发过程是信息不断传递、想法逐步系统化和流程化的过程。
网上有个挺有意思的图，反映的是几个大厂的组织结构方式
同时很直观的可以看出，里面其实也反映了产品和组织结构是紧密相关的。
因此也有一种说法，就是组织有多烂，产品就有多烂。也因此而有产品基因理论，阿里系的就是搞不好互动社交板块，腾讯系统的就是没法做好交易业务。
没有哪种组织沟通形态是比其它更优秀的，只能在这个过程中不断调整和尝试。开放式的沟通体系有助于集合力量，但是相对地，其沟通成本也成 2^n 上升，所以必须要用技术标准来约束参与各方的行为。而制定技术标准本身，就需要无数的扯皮。opengl 没 directx 发展得快，可见 directx 在微软的大树底下好乘凉，从解决问题的角度来看，封闭独断也不见得是坏事。
而能够推动沟通形态成功转变的，无一不是英雄式的人物。IBM PC 的诞生，打破 IBM 封闭的体系，用全新的开放式体系标准，才能成就 IBM PC 平台的辉煌，并超越苹果的MAC；苹果，当组织有个强大的核心灵魂人物时，他能带动整个产品体系的高效地发展，带给世界 iphone / macbook air 这样的优秀产品。
麻烦的是在组织中，往往会出现位高权重的人插手想当灵魂人物，但是水平又到不了控制全局的情况时，所有下边的人都只能忙于帮忙擦屁股。产品没有核心，没有边界，没有过程控制，没有量化管理，没有演进计划，一切成果只在 PPT 上。
时间
康威定律原来是以 right 来表示系统没法完全正确，在中文中一般表达为完美。
这里反映的是真实世界和系统建模之间差异的问题，在真实的世界里面的细节太过于丰富，是无法完全通过一两次的软件工作完成的，我们完成的是对现实世界的业务建模。
每个工作不论长短，总是会有结果，即使这个结果是未完成。既然无法兼顾所有的细节，那就尽量把最核心的功能实现，让流程能跑通，有点小bug无关紧要。用现在的概念表达，这个就是敏捷的思想体现，当然，敏捷还要有持续的交付。
除了时间之外，这条规则也可扩展到资源层次上，开发资源、运营资源，我们需要考虑的是在有限的资源约束下，达成特定的项目目标，提高投入产出比。
系统与组织
组织的沟通结构影响系统的设计，而系统要运作好，也需要组织架构上配合系统结构。所谓异质，指系统架构和组织结构分属于不同的东西，而同态，表明两者是会趋向于类似的逻辑结构。
以开发团队为例，如果采用前后端分离方式系统结构，团队一般也要分为前后端。一方面，各自有明确的边界后才能让沟通更加顺畅；另一方面，对人力的水平要求降低，毕竟不是每个人都能全栈工作，每多掌握一种技能其难度都会翻倍。
运营上类似，如果有多个运营的组织，那么系统上也要有相应的分组权限设计，各司其职。
有什么样的团队，就要有什么样的系统，不能单纯指望系统能解决团队组织上的问题，也不要指望团队能一定适应别人高大上的系统，两者都在不断的相互促进中。
分解
大系统的分解相对来说是个比较好理解的过程，像现在火热的微服务化、FaaS，都是在倾向于把单一应用分解为多个子系统。
但分解从来不只是技术上的事情。正如前面几条，这样的拆解是否真正满足组织沟通结构，是否与组织结构一致?强行进行拆分，只会适得其反。
分解给系统带来一些好处，包括：
（1）各个模块更加专注于小块业务，一如社会化大分工，专业化带来更高的业务效率；
（2）可单独为各块进行优化，以《架构真经》的描述，就是复制-拆分不同-拆分相同的过程;
（3）适当建立边界，提高系统健壮性，避免单一错误快速传播到整个系统
分解还会带来额外的分布性计算的问题，经典的CAP问题，即一致性、可用性、分区容错三者不能同时满足。特别是对于强事务型的系统来说，每拆分出一个子系统，都需要相应的事务协调，带来的非常庞大的开销。
思考
当我们在进行系统的设计时，系统的抽象这个关键的步骤中，需要思考组织对系统的影响，在其中平衡我们的长远目标和现状。
新的技术层出不穷，IT 界是个起名字大师，各种概念多得数不清，每引入一项技术都会带来相应的代价。
组织与产品密不可分，分析系统问题时要关注组织因素。
