所谓康威定律
有一位叫康威的人，提出一个观点：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。其实，这里的系统并不局限于软件领域的系统。康威对其定律又做了具体解读：
-
组织沟通方式会通过系统设计表达出来。
-
时间再多一件事情也不可能做得完美，但总有时间做完一件事情。
-
线型系统和线型组织架构间有潜在的异质同态特性。
-
大的系统组织总是比小系统更倾向于分解。
组织沟通方式会通过系统设计表达出来，沟通成本随着团队成员的增加而以几何级数增加。线型系统和线型组织架构间有潜在的异质同态特性，这句话说白一点就是，你需要构建什么样的系统，就搭建什么样的组织结构。下面我们会融合案例来看看这些逃不过的原则。
所谓技术债务
技术债务是由Ward Cunningham在1992年的报告中创造的一个比喻，被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。它和金融债务非常相似。一个人贷款了就会产生债务。如果他定期还款，那么所创建的债务是可以接受的，不会产生进一步的问题。但是，如果他不还款，就会以利息作为惩罚，并随着不还款次数的增加而增加。如果这个人很长一段时间不能支付任何款项，那么应计利息使得他更难以偿还债务。在极端情况下，该人不得不宣布自己破产。
为了快速做业务，采取简单粗暴的方案是大家表示支持的。临时方案的毛病不在于这2个月临时了，而在于这个临时上线之后，再无人管了，俗称“有人生、没人养”。1年如果做5个临时方案，就等于欠了5笔债务。欠债并不可怕，怕的是没有偿还计划，或者借口没有时间，或者借口等业务不那么高速发展的时候。吊诡的是好的业务一定是永远都没有时间的，而差的业务确实不用发展了，因为被下线了，或者整个公司close了。So，珍惜高速发展的业务，记得去更换引擎，偿还债务，欠的，迟早要还的。有关技术债，推荐当当史大官人在周评比中名列前茅的文章：当技术宅遇到技术债，我个人觉得是这方面有调皮有调性的好文章。
以三个case来看看研发活动之痛一次接入效率优化
以真实的X业务为例，在去年年中的时候，一个全新模式的业务接入需要多达10天，历经17个环节，8个团队。如下图所示。
我们确定了几个策略以期带来改变：
-
减少协同
-
减少环节
-
提升效率
为什么要减少协同呢？我们前面讲过，组织沟通方式会通过系统设计表达出来，沟通成本随着团队成员的增加而以几何级数增加。关于沟通成本，人月神话给出了很简洁的答案：沟通成本 = n(n-1)/2，n=项目成员。如果按一个团队1个成员作为接口人参与跨团队协同，那么8个团队的沟通可能就达到87/2=28；而3个团队的沟通值算下来是32/2=3。
为什么要减少环节呢？环节越多，涉及的组织和团队就越多；减少组织协同必然要减少环节。有报道说某市一家工厂的一个基建项目，在申报过程中，一共盖了745个公章。流程如此繁琐，必然会影响办事效率。软件研发亦是如此。
我们再来看一下提升效率！减少环节，减少协同，自然效率就高了；有哪些减少协同的方式呢？
我们来看一些例子：如果一个团队有3个team在协作，而每个team都是前端、后端、测试职责分明，那么需要协同的环节必然就会很多。比如team1后端开发交付测试、team1后端进行验收测试、team1和team2进行功能联调等等。
如果尝试进行能力合并，就是全栈型团队，那么可能的模式就变成下图所示：
全功能团队虽然也有编写代码、单元测试、接口测试、集成测试等环节；但跨越组织的沟通已经减少了很多。
我们再尝试一种变化，因为设计系统的组织，等于组织内和组织间的沟通结果。
这个组织沟通图背后的架构关系可以如下示意：
总结：组织关系和架构息息相关；沟通成本往往由于组织协同方太多造成；应该从外部视角来组合组织关系；尝试通过抽象、构建通用组件来尝试达到能力复用；尝试对于用户或者内部客户提供统一受理界面。
重复的轮子
软件开发领域有一个流行的原则：DRY，全称是Don’t Repeat Yourself，我们一般翻译为：不要重复造轮子。关于要不要造轮子，有一篇非常精彩的文章：使用开源项目的正确姿势，都是血和泪的总结！
我们抛开其他，尝试聊聊轮子与组织的关系。首先，如果是同一个boss下面，已经有一个轮子了，兄弟团队用还是不用？如果不用，boss肯定要跟你算账！尽管你背后在骂这厮做得有多烂，你还得用。如果是不同组织的轮子呢？就不一定了，如果是一个业务研发型团队，是没有时间去造中间件轮子的了，但是可以搞些common-tools之类，这些也可以作为创新产出去交差。而且我们是绝对对同类产品表示嫉妒的，要千方百计证明对方很low，我解决了世界级难题。当然另外一个团队也是这样向老板汇报的。最终这些轮子越来越多，很难推广，也无法解决全部问题，因为问题域很广，没有银弹。
我们以下面这个案例来说一下。如下图所示：
-
提需求给基础平台
-
自己做能力升级
-
找找有没有别的轮子
方案1是最好的，专业的事情交给专业团队；方案2是不得已而为之；方案3是折中解决方案。也就是方案3优于方案2，但我们习惯于做方案2，造一个轮子，因此形成了鄙视链。
你需要构建什么样的系统，就搭建什么样的组织结构；这句话有一种逆向作用力。为了满足xx领域的监控能力，我们在基础平台的基础上引入了xx实时计算，xx指标管理，xx模型；那么我们成立了一个团队A来做这事；做着做着，我们就形成了一种认知，团队A就是解决这个问题了，而且我们很强大；我们致力于解决更多的类似问题；后来我们发现团队B、团队C也是通过自然生长解决类似问题的。那么问题来了，从公司角度看，A、B、C做的事情应该合并；从各具体组织看，会不断证明别的团队做的会满足不了我的需求，我是应该留下来的团队。
总结：你要什么样的系统，要搭建什么样的组织结构；一旦搭建了这样的组织结构，可能带来逆向作用力，从而导致重复建设、效率低下、部门墙，且最终可能都没有对一个问题域打穿，给合作伙伴或者客户提供了非一站式的解决方案，陷入各自为政。
在提出解法前，我抛些原则：协同、赋能、动态组织。首先明确一个动态组织的概念，组织是为业务或者某些目标服务的，组织应该具备灵活性、动态性。一个长期稳定的组织，可能没有活力，或者没有寻找新的挑战空间。其次，协同原则，意思就是孤胆英雄不能成事已然是IT界的共识了，孤胆团队同样难以成事。经常有人讲站在巨人的肩膀上，登高望远。所以一个组织要明确自己的目标，而且明确多少事是协同哪些干系方去拿到；一定有很多不用自己做的事情，笨不是理由，没看清楚会让团队泥足深陷。赋能，是基于协同这个共识来的，中间件团队要赋能业务研发团队自不必说，业务研发团队之间也可以相互赋能。那些共性问题，没有必要重复造轮子。这里引入了一个非常关键的因素，就是考核！团队A的主管如何看待A这个团队，他可能就把某工具做成当目标，其实团队A的主管的主管的目标是达成5秒的异常检测能力，他并不关注监控的一部分能力是谁提供的。OK，基于以上的讨论，可以给出一些解法，但不限于此。
如上图所示，中间件团队可以把监控平台做成内部开源模式，是完全开放，还是提供基础能力层，开放层这样具体的细节且不讨论，其他业务团队都可以贡献代码，业务团队的优势是离业务场景很近，有具体的场景驱动；这样还可以解决A、B、C团队的优先级问题，全部List给中间件团队，不知道猴年马月了。
如上图所示，业务团队A和中间件团队可以持续共建某些基础能力，可能业务团队A是需要赋能的大户，而且所需要的成本很高，故长期共建。基于我们说的协同、赋能、动态组织原则，业务团队A在完成使命后可以在对应的组织内重新确定新的目标。同时，赋能原则，共建的成果，可以为业务团队B、C服务。对于业务团队B而言，可能投入1-2个人，搞上2个月自己的需求就满足了，那么他们就撤出。
平台发展vs业务发展
最近陈康贤写了一篇谈演进式架构的文章，我记得大致是对于成熟的业务领域可以采用平台式架构。我非常认同。之前也有一些大咖提出架构是演进出来的，而不是设计出来的。总体来讲，演进是必须的，前期设计做多少合适是值得探讨的。我个人的一个衡量标准是对于方案A、B进行评估，如果方案B可以更通用，而付出的成本在可接受范围内，优先选择方案B。不做BDUF是大家的共识，而艺术在对于“度”的把握。
许多人都会面临一个问题就是平台发展vs业务发展。按理说平台应该随着业务一起发展，但是如果每个需求都是堆砌式地上线，那么就是构建了一个一个的烟囱。我们期望的是在一段时间后，相似度高的、同类型需求可以拥有快得多的上线能力。
关于平台发展和支持业务，以及不同场景不同阶段的业务架构原则我有几个观点。
-
架构方案和业务形态息息相关。
-
架构是演进的、发展的；架构没有最好，只有适合。
-
技术债要做清偿计划。
-
不要在下雨天去补屋顶。
架构方案和业务形态息息相关
我之前亲身经历了一条产品线，完全是试错型的产品线。我们在设计之初，对于模型共同层做了抽象，后来五花八门的产品长在上面，公共的内容越来越少，反而导致了系统调用链路增加；代码编写的复杂度增加。1年后，这条产品线全线关闭！从这个case来看，最适合的就是满足业务快速试错，可能烟囱式架构是最合适的；甚至产品之间有一些代码重复，但各team各司其职，是最快反应，是最小的研发响应单元。对应到康威定律的组织和架构关系，也是依赖最少的组织，沟通成本最低。
如上图所示，烟囱型架构在不确定产品线的试错有优势，对应的组织构架也应以简单、快速响应为特征。
架构是演进的、发展的；架构没有最好，只有适合。
我再举一个例子来说架构演进这事。随着业务发展，上了规模，类似的诉求会凸显，因此沉淀为越来越多的平台。如下图示意：
除了需求相似性、平台要求相似性导致的架构发展以外，还可能有，我们对领域本质认知的升级。比如在支付宝渊源的发展过程中，我们先后使用过红包、实时优惠、商户优惠券等产品。这是烟囱式架构发展下的产物。下图示意为一个红包产品的展示。
行业也有其他类似券的东东，如下图所示：
如果简单地看，券和红包是两类东西。但是，我们在产品上形成了如下定义，就可以视作一类东西，则可以对它们进行统一的抽象和管理。
券定义：
-
是一种票据，作为券发行方和拥有方之间的凭证，具有一定的价值和法律效应。
相关干系方：
-
券的发放方（提供权益）
-
券的拥有方（享受权益）
-
劵的发放工具（是券发行方向拥有方发放券凭证的工具）
券形式：
-
以介质分类：纸质券、电子券
-
以使用方式分类：入场券、礼品券、提货券、代金券、红包、打折卡、满减卡等
可以把券作为基础产品，在业务形态上可以包装为打折卡，满减卡等用户感知的产品或者是营销工具。
技术债要做清偿计划
前一段，参与了一个关于技术债务的讨论。技术债务确实一个惹人讨厌的东西，业务逼着你跑，你不跑不行，可能跑着就累死了；你停下来歇会儿，搞搞技术改造，又可能被业务压力压死了，反正都是死！关于技术债务我提了4个观点：
-
由于技术人员水平不行，意识不够，所以越写越烂。
-
developer都有一颗积极向上的红心，但是他们不知道如何做才是好的。
-
上行下效，没有靠谱的Leader，架构师，大家都是懒惰的，不想去还债。
-
有华为的朋友表示，永远的业务压力，我没时间；其实所有公司都一样滴，赶着交付，哪有时间去清偿。
关于债务清偿，也总结了务实接地气的几个思路：
-
构建质量保障体系，让我有勇气动手动刀。比如接口测试、单元测试，通过CI持续反馈，这样我有50%的勇气来做重构。
-
对于遗留系统，没出问题的地方，你不要动它。出问题的，修复并补充测试代码。如果更进一步，对于高危的功能和模块可以做定向增强。
-
招募优秀的工程师，好的作风和习惯可以影响整个团队。
-
抓住痛得不行的时候大作文章。平常说持续集成，可能团队成员没有感受到好处，出bug了，再回顾看看；copy-paste代码总有一天不能满足更复杂的需求，这样从心理认同上，大家觉得必须重写了。抓住这样的机会，构建品质高一些的代码和质量防线。改变一个人是非常难的，抓住这样的机会很重要！
不要在下雨天去补屋顶
马老师有一金句：不要在下雨天去补屋顶。做软件研发，做架构也是一样的。当一些重点战役型项目让你喘不过气的时候，你去做理想架构无异于找死。这里一个观点就是技术、架构始终为业务，为商业服务。无论从走出舒适区，还是从架构发展来讲，一定要找准时机来做架构升级。这个升级是基于对业务本质的不断认知，否则就是南辕北辙。我们团队曾在一次重要架构改造的过程中，架构方案确定比新业务来临早了3个月，这样刚好通过一个小业务的切换，快速上线。然后在战役打响的第二个月新架构派上用场，3个月的时差足以改变许多东西。
因此，我们要记住，不要在下雨天去补屋顶！补屋顶包括偿还技术债务，包括架构的升级改造！
总结一下：康威定律及其推论告诉我们，要什么事情，设定什么样的组织结构；同时做不同的事情，要允许动态弹性组织结构，不要被组织束缚；再进一步，跨越组织，立足协同、赋能可以做出更大的组织成效；技术债务这事不要等到下雨天才偿还，做业务和平台架构发展平衡的艺术取决于在一定时间和环境下的目标，技术人员不要永远处于被驱动的状态！研发之痛，是一个复杂的调试性问题，没有银弹！
来源：https://www.cnblogs.com/zhjh256/p/10634403.html