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 个,然后执行。《华杉讲透孙子兵法》中更详尽一些。我写一些,不仅对指导架构师工作,对所有需要自我管理的岗位,都非常有意义。

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

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

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

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

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

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

……

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

……

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

……

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

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

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