转载

『每个架构师都应该研究下康威定律』

InfoQ 中国在 2016 年，发表过一篇文章，杨波的《每个架构师都应该研究下康威定律》。这篇文章对当时的我，触动是非常深刻的。一些说不清道不明的经验，被别人用浅显易懂的道理，讲得一清二楚。

康威定律是很早就听说过的，后来陆续又有一些接触，每次时隔一段时间再做了解，就会有非常深的触动。我理解，原因无他，因为它聚焦在组织架构和系统设计的关系上，而这两者，一个是架构师目标，一个是架构师的手段/工具。文中用很简短的一句话，讲清楚了这中间的关系。

系统架构的目标是解决利益相关者的关注点。

这句话简直太重要，太精妙了。

1. 架构师的目标，是各个利益相关者的关注点

很多人对架构师的误解，都以为是架构师是技术执行，是 top-level coder，对 coding 的结果负责。这就犯了以表象取人的问题。为什么？我后面再提。

架构师首先应该关注的，是项目中，各个角色，各个利益相关者，他们的利益诉求，他们在项目中的焦点。根据这些焦点，得到一个权衡的方案，并取得最大限度的支持。

2. 架构是权衡的艺术

权衡的英文表述比较准确一些。 trade-off 。利益交易和平衡。

权衡的方法是博弈，无论是纳什均衡还是帕累托最优，权衡目标是达成一个相对稳定的博弈结果。这个结果，就是架构的目标需求。

所以你看，脱离实际场景谈『架构』，本来就是虚空的。

3. 架构首先是业务架构，其次才是技术架构

道理很简单，业务架构往往涉及最直接的利益分配，从市场到产品到后勤保障，通常都对业务指标虎视眈眈。产品技术指标他们并不关心。

从工作流程上来讲，业务架构决定产品设计，产品设计决定技术设计。说业务架构是技术架构的前置步骤，一点不为过。

唯一的例外，可能就是大厂里面做平台产品研发的案例了。从无到有形成一个平台，比如阿里 IaaS 云。商业模式不清晰，业务架构反而受制于技术架构。不过这种机会今后出现的可能性，越来越小。

4. 技术架构是工具/手段

确定了各个 stakeholder 的 key points，剩下就是怎么做的事情了。技术手段、技术架构，不过是实现平衡的工具而已。通过技术架构，将权衡的方案，表达出来，这是一个称职的架构师，秀于外的工作。

我个人对架构师的定义是，以权衡项目中各个利益相关方的利益关注点为目标，以技术设计为工具和手段，以持续的产品技术服务为交付物的产品研发决策者。

所以回过头去看，架构师的工作中，技术架构的部分，优先级排不到前列，称得上是最基础、最『本分』的技能。技术好，技术设计灵活，不是一名架构师值得炫耀的资本。架构师值得炫耀的，是他能够在复杂纷扰的环境中，仍然可以理出线头，正确判断形势，做出合理的架构设计。

比方说，一名做 ToB 业务的 SaaS 平台架构师，既往工作中，以项目经理/甲方的利益诉求为主，以己方销售的利益诉求为辅，养成了习惯。一个需求做不做，怎么做，第一问己方销售/甲方，其次问项目经理，总可以得到答案。有一天，他去到一家做 toC 产品的公司任架构师，他面临的 stakeholders 发生了翻天覆地的变化，『甲方』成了成千上万的个体，怎么去问每个个体，他们的 key points 是什么？所以这位架构师的转变是，以直接上级的利益诉求为主，以产品经理的利益诉求为辅。那么，这个架构师，很明显就犯了最低级的失职。即便他的技术实力再强，首先目标就错了，谈何取得胜利？

雷军讲的，以战术上的勤奋，掩盖战略上的懒惰，大概也是说这个意思。

啰嗦一句。无论是 toC 产品还是 toB 产品，架构师首先应该予以重视的 stakeholder，都应该是财务上销项对应的一方。也就是为公司提供入账的一方。有人可能会觉得奇怪，toC 产品不应该是用户为首要的 stakeholder 吗？真不一定。如果是付费用户，那么他们是公司账上销项对应的一方，他们算首要的 stackholder。如果用户是免费使用公司服务，那么应该把他们看做产品/服务的一部分，把他们看做产品/服务的资源，而不是 stackholder。既然是资源，能为己所用就可以；既然是产品的一部分，只要产品不散就可以。不需要过多考虑免费用户的诉求和偏好。

有些免费产品讲情怀，前提是他们活着不成问题。没干爹可抱的企业，先把自己的财务账算清楚，努力维持公司现金流为正，先有资本活下去，才是正道。别人在山顶为踏足云顶做赋，那是情怀，你在山底谈云，那是浮云。

5. 架构不止『偏技术』，不是每一名架构师都需要『偏管理』的搭档

架构师的责任，是交付能够让至少大多数 stakeholder 满意的架构方案，并且落地执行，交付一个 predictable 的结果。

一个需要对交付结果负责的人，就不能是一个不懂『管理』的人。沟通、协调、跟进、攻坚…… 任意一个环节，都离不开管理相关的工作。给架构师配一名『偏管理』的搭档，我猜是望文生义的误会。

有些项目庞大，架构师的职责由一个团队承担，架构师团队中，有一名首席架构师兼任团队的管理协调。但并不是说，非首席架构师，就不需要懂管理。真要是不懂管理，最多算研发骨干，肯定达不到架构师的要求。

此外，一名好的架构师，一定是一位 nice 的 listener，否则怎么去沟通和判断各个 stakeholder 的 key points 呢。一名『偏管理』的搭档，究竟能帮这位又 nice 又善于倾听的架构师做点什么呢？真的很难讲。

6. 架构师是一个团队的工作

架构师需要沟通，需要协调，需要以技术方案为工具，需要完成设计，再交流，然后 sell idea，获得大多数 stakeholder 认可。还需要落地项目，交付给大家一个 predictable 的结果。这样的工作，绝不是一个人能搞定的。需要一个主心骨，具备较强的主人翁精神/企业家精神，以及相对较大的（临时）授权。架构师的工作，远不是单打独斗的宅男可以完成的。他需要一个团队。

在架构师的选择和授权上，其实就是一个择人任势的过程。架构师在他下属团队的建设上，也是一个择人任势的过程。两部分，前者属于宏观层面，择人为重；后者属于中观层面，择人和任势并重。

7. 康威定律是连接组织架构和技术设计的桥梁

康威定律的意义在于，告诉我们，把 stakeholder 的 key points 转化为技术设计时，需要遵循的一个规则。

举个例子，一家以市场推广为主导的互联网金融公司，建设 SaaS 平台，架构师的第一反应应该是，市场/推广/获客相关的功能，占比要比其它功能模块重，要更复杂和全面。这就是康威定律的具体体现。公司以市场为主导，市场相关的 stakeholder 话语权很重，架构设计必须要得到这些 stakeholder 的认可，才能算过关。聪明的架构师，会先跟市场部领导和骨干沟通，获取他们的利益诉求，架构设计中把市场相关的功能放在最前面，予以强调。反之，架构师以技术炫技为架构设计的亮点，出来的方案一定不会获得市场部相关领导的认可。最后做出来，很大概率会被市场部同事 diss，连带架构师在直属领导心目中也会扣分。

我曾经试图找康威定律的反例，很可惜，越想找这样的例子，越发觉康威定律是颠扑不破的真理。原因就在于分工界面上。以分工界面划分细分工的岗位，为这些岗位分别制定工作流程和质量评价标准，几乎成了每个现代化组织的必选项。通俗来说，就是按照岗位，把大家伙儿分个类。每个岗位都有独立的工作流程，和考核指标。岗位和岗位之间，由工作流程中设计的『工件』（也叫交付物）来连接。大家在脑子里面想一想，其实这就是一个模块化的系统。对不对？模块化设计的思想，在这里也是适用的。低耦合，高内聚。高内聚先不说。低耦合意味着，分工界面一定要足够简洁。对应在系统架构里面，一个主要功能模块，一定会对应一个/一类岗位的责任人。这样算下来，一个岗位，一定会对应一组边界清晰的系统模块。否则，这个岗位的分工界面上，一定会发生工件难以验收，工作难以考核的情况。

多说两句。过去讲康威定律，举例大多是反过来的。例如维基百科『康威定律』词条中的一个例子。

如果你有 4 个团队在做一个编译器，你会得到一个 4 遍处理的编译器。

我觉得这种认识在现实中恰好相反。

因为有什么样的组织架构，就会有什么样的系统设计。这是过去几十年那个时代的特征。同时代的特征还有，对代码空间复杂度或者时间复杂度的极致追求。那时的软件研发中，硬件成本占比高，人力成本占比相对较低，且计算机程序员数量远不如现在多，程序员的成果最好能尽量复用。所以才会有组织架构决定系统设计的逻辑。

现在是人力成本占大头，程序员数量供过于求的时代。特别是在中美贸易战之后。在这样的现实中，什么样的组织架构不重要，系统设计符合产品特点，交付的服务能让公司内外部客户都满意，才最重要。所以反过来，需要做什么样的产品，权衡出什么样的系统设计，研发团队也需要做相应的调整，以组织架构匹配技术架构的设计。如此才能职责清晰地完成工作。

8. 胜可知而不可为

刚听了华杉老师的得到直播，《跟华杉学品牌营销》开学典礼。华山老师很厉害，《孙子兵法》快成了他个人品牌的超级符号。

直播中，看到华与华公司的最大的会议室，名字叫『知胜』，取自孙子兵法中『胜可知而不可为』这一句。听到这里时，给我很大的启发。

华杉老师说，他们做品牌营销，也是可以知胜的。一个品牌案子做出来，能不能成，他们是可以知道的。怎么知道？直播中华杉老师没细讲，我记得大意是说，他们会通过周会，周报的形式，做 list 的形式，把战略目标缩减为 1 个，把关键动作缩减到 1-3 个，然后执行。《华杉讲透孙子兵法》中更详尽一些。我写一些，不仅对指导架构师工作，对所有需要自我管理的岗位，都非常有意义。

他（指东汉史学家荀悦）说要确立一个策略来决胜，无论是战争还是搞改革，公司要做什么事，主要有三个要点。

第一是形，是大体得失之数。就是判断大体行不行。

第二是势，是临时之宜、进退之机。到了现场随机应变、顺势而为，就是讲势。

第三是情，是感情的情。用我们现在的话来说，应该是意志力，看你的意志够不够坚定。对于主帅来说是看你的意志力，对于团队来说是看你的士气。

上面是讲以什么维度『知胜』。

（《孙子兵法》对于势，）记住四个字最关键：先胜后战。我们把它翻译一下，就是赢了再打。

……

『孙子曰：昔之善战者，先为不可胜，以待敌之可胜。不可胜在己，可胜在敌。』

……

『孙子曰：故善战者，能为不可胜，不能使敌之可胜。故曰：胜可知，而不可为。』

……

一句话，人管得了自己，管不了别人，先管好自己再观察别人，别人如果无懈可击，我们是没有办法取胜的。

我们管好自己，可以保证自己立于不败之地，敌人也无法战胜我们。这是关于从哪里知胜的。先做到不败，再等待敌人给我们送来胜利。

做架构师的工作，见效的周期往往很长。像华为飞总那样的大拿，一个项目要一年以上见收益，半年一次述职/考核，这样的架构师，最重要的是确保自己的工作是正确的，能保证不败是第一步。所以有趣的一点，真正的架构师，特别是做大架构的架构师，做出来的架构通常都是四平八稳的，技术设计上反而很少亮点。因为要控制风险。一个小风险经过这么长的时间跨度，这么复杂的执行流程，都很容易放大。经过历史检验的老技术更稳妥。做大架构，就是图个『能为不可胜』。炫技的大多是菜鸟。

原文 http://i.am.simonkuang.com/post/architect-need-to-know-about-the-conway-law/

正文到此结束