作者 | 肖然

出品 | CSDN（ID：CSDNnews）

我们在之前的文章中介绍了数字化企业敏捷建模DEAM方法（Organization Structure Modeling）的基本思想和框架。针对企业架构的落地实施，分别从价值建模、领域建模和组织建模三个层面完成业务架构、系统架构和技术架构的持续构建。三个建模过程域强调能够通过跨专业的协同，建立更多上下游的互动，从而能够在协作的过程中让共同的语言体系得到持续的养成。

（DEAM框架中“组织建模”的位置）

在技术架构层面，仍然存在着不少“只要图纸画的好，剩下只是代码问题”的偏见。真正经历了大型软件项目的老兵们都知道最难的并不是第一次画图纸的问题；而是随着时间推移，不断增加的新需求的持续实现问题。面对着前期架构设计上并没有预期到的需求，如何能够在系统持续迭代过程中保持架构的完整性，是一个巨大的挑战。

走进一个3-5年的系统，很容易发现不但架构上没有了完整性，甚至于过去的需求都没有人讲的清楚。看似面面俱到的需求文档仅仅是一种幻象，实际的系统功能早已和过时的文档相去甚远。所以在技术架构上，和业务及领域一样，我们必须关注“演进性”。我们需要把过去静态的“盒子图”变成具有牵引性的“认知地图”。

我们都知道地图是具有坐标体系的，比如大家常用的导航是根据全球通行的经纬度坐标；而物体在地图上放置的位置有对应的具体含义，在正北体系的地图中，我们知道北京应该放到天津的左上方，代表着北京在天津的西北方向。同样道理在看待软件架构时，我们应该构建一个带有坐标系的地图，而且这个地图还必须考虑一个核心维度——时间！

（视图和地图的最大区别在于地图上物体的放置位置是有显式意义的，比如根据全球共识的经纬度坐标体系，每个国家、每个城市都有自己固定的地图位置。）

下面就让我们一起来看看如何构建起技术架构层面的这张可持续管理的“技术架构地图”。

逆康威定律的思考

首先让我们来辩证一下这张地图上应该放什么“物体”，或者引用金融行业最基础的问题：地图上的“标的物”是什么？

如果不假思索，大多数人会说是系统、服务这样的技术模块，但康威定律在这方面给了我们非常不一样的思考 —— 组织形态决定产品形态：

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)

康威定律明确了组织设计的产品/服务等价于这个组织的沟通结构。经过一系列的实验证明，针对同一个用户需求，产出软件的内部组件数是同参与设计和开发人数成比例的。然而，这也就意味着组织架构一旦形成，其生产制造的系统或产品的内部架构就固定了。从一个时间点出发这不是问题，因为我们可以有专家针对当下已知情况设计出相对完善的架构。

但如果市场和客户需求发生变化，就会和现有架构产生不匹配。随着变化的日积月累，我们会发现开发新功能越来越艰难，到最后甚至于一些功能在现有架构上根本就无法支持。这样的经历相信很多软件研发组织都有切身感受，甚至不少组织正在经历着这样的架构“腐化”。

由此业界也提出了所谓的“逆康威定律”，就是要通过保持组织结构的灵活性来高效响应外界的持续变化 —— 即通过改变组织结构来驱动软件系统内部架构的调整，从而能够在持续变化的环境中保持内外部的匹配。

根据逆康威定律，我们构建的这个“技术架构地图”的标的物就应该是为了研发相关产品和系统而相互关联的一组团队。

我们中国有句俗话 —— “船小好调头”，为了灵活，大家自然是希望团队规模小。然而随着“软件吞噬世界”，随着元宇宙的浮现，软件的复杂度是与日俱增的。复杂度增长带来团队规模的扩大是不可避免的现实。这里也就产生了一个矛盾的情况，如果我们划分过细，就很容易陷入精细化管理的怪圈，让后续的调整变得困难重重。

另一个极端情况，是否有可能在团队规模变大时，仍然坚持不拆分，这样沟通结构就保持了最大限度的灵活性呢？显然答案是不可能。团队过大不仅很难保证组织效率，实质上就难于形成一个团队。

邓巴数（Dunbar's number）某种意义上给我们提供了这样的团队规模“上限”，特别是在软件研发这样高度依靠脑力劳动的领域里，这种团队人数的限制就越发明显。

（邓巴数，%27s_number。能与某个人维持紧密人际关系的人数上限，通常认为是150人左右。对于大型软件研发组织，很多企业把150人作为拆分办公室的一个阈值。）

邓巴数提醒我们在面对复杂软件研发时，必然是需要划分团队的，只有控制团队规模才可能保证研发的效能。这就产生了类似amazon经典的“2 pizza team”的结构，每个开发团队的规模控制在了10人左右。为了追求高绩效团队，我们希望划分出的小团队是能够共享目标、协作亲密无间的，所以企业往往追求的小团队规模是瞄准了更小的15人。

值得警惕的是，小团队结构并不代表我们能够突破康威定律的魔咒，实际上“小团队僵化”在很多所谓实施了敏捷开发的组织里比比皆是。比较典型的现象是越来越繁琐的集成联调工作需要协调；越来越控制不住的“小”团队规模扩大，从10人很快到了15、20人。

所以真正长效的软件技术架构治理应该来自于小团队组织架构的设计和演进，而如何去定位每个小团队的职责、如何设定每个小团队的演进路线就成为了技术架构设计的关键。

团队拓扑带来的突破

确定了我们技术架构地图上的物体是互相关联的团队后，让我们来看看具体如何认定这些团队的职责，并针对性地设定团队的目标和工作方法。

这是一个曾经让软件研发组织非常头痛的问题，由于软件相关技术发展迅速，并且种类繁多，划分和定位小团队比较困难。在落地敏捷开发时，我们也仅仅是给出了所谓的“特性团队”和“组件团队”两种模式。前者主要是面向业务需求的端到端交付，后者更多是从技术模块化的角度，形成技术沉淀和复用。这样的基础划分实际上并不能指导大型研发团队进行有效的团队设计，往往造成业务希望全面特性团队简化沟通，而技术希望大量组件团队固化架构。

团队拓扑（Team Topologies）带来了这个领域新的突破，改变了团队划分的出发点 —— 团队的认知负载（cognitive load），简单讲就是一个团队可以驾驭的知识工作的极限。前面提到了邓巴数的原则，为了小团队的高效运作，我们希望控制每个小团队在15人左右。而15人的团队在认知上就是有极限的，我们不会期望这样一个小团队能够掌握一个上百万行代码库的方方面面。如果这个百万行代码就是我们的一个应用系统，那么组织就需要划分成多个这样的15人小团队，每个团队的职责和互相之间的协作就需要清晰定义。团队拓扑的理论和方法就这两个方向给出了总结和提炼，指导大家能够从组织架构的视角去完成技术架构的设计。（记住逆康威定律！）

（团队拓扑Team Topologies知识图谱共享经济建模问题，来源于《高效能团队模式：支持软件快速交付的组织架构》一书作者总结。）

首先让我们来看看团队拓扑在团队职责方面的定义，分为四种类型的团队。

四种类型团队的分类相对有效地帮助组织架构师们建立了一个模型范式，当发现一个团队所处理的业务有超越这个团队负荷极限时，我们可以从不同的视角去划分工作，推动形成适配的团队结构。

面对复杂场景，团队拓扑通过团队职能的分工给我们提供了不同的解决方案视角。当然仅仅是团队分类显然还是不够的，还需要明确团队间的“接口”，即团队间合理的合作模式。这个方向上团队拓扑提炼了三种典型的合作方式。

以上三种合作模式的提炼相对抽象，但已经给我们提供了很好的切入点，团队拓扑社区也在通过实践案例总结Team API，团队接口。大家可以参考Github 上的模板来细化团队在对外协作方面需要具备的能力： 。

通过分类团队和定义团队接口，团队拓扑也给我们揭示了过去忽视的小团队管理的复杂度。正是由于这种复杂度的存在，才造成我们在技术架构的长期演进上知易行难，开始的热忱往往在日常各种琐事中消磨殆尽。所以，作为一个大型研发组织，即使我们难于一步过渡到采用组织架构来描述技术架构的实践，也应该在当下开始增加组织架构的梳理到技术架构设计的过程中去，让逆康威定律不再是停留在PPT上的根因分析。

组织建模的有效实践

借助团队拓扑，我们明确了“技术架构地图”上的标的物（团队）的分类和之间的关系，是时候讨论一下地图的坐标系了。本着敏捷价值驱动的一贯原则，坐标系的一轴应该是“价值”；而这个数字化时代组织的基石就是“以客户为中心”，必然要求我们从客户视角来审视价值。

地图上的物体——团队——除了分类和关联关系外，还需要考虑在一个企业里的定位。比如大型商业银行可能有一个相当规模的自有云平台团队，构建其自身的私有云；而一些小型金融机构可能就只有一个小型的云赋能团队，保证业务开发团队能够使用好公司合作的云平台。这样的考虑在过去的IT组织里是一个经典辩论：购买还是自建（Buy or Build）。

基于这样的两个考虑，行业里已经有一定认可度的Wardley Map进入了我们的视野（）。当然这里我们更多是采用Wardley Map的坐标体系，并不会当做战略定位工具来使用。

Wardley Map采用了“价值链”（Value Chain）作为纵轴，横轴则直接从“演进”的视角来审视地图上的这些组件。我们就横、纵轴做了简单翻译和解释如下，帮助大家理解这个坐标体系。

初创（Genesis），对组织来说比较创新的能力，往往也较难从市场上直接获取，比如希望构建自身的元宇宙空间。

定制化（Custom），相关能力部分已经标准化，但组织需要根据自身需求做定制化，比如很多企业在容器云的管理上都基于K8S做了定制化的平台开发。

产品化（Product），对应的能力标准化程度较好，可以通过外部购买来获取，也可以根据不同阶段按需购买，如SaaS服务。

通用化（Commodity），对应的能力市场通用化程度较高，对于组织来说比较容易随时获取，类似水、电、气，比如采用公有云的基础服务，按照使用量来进行付费。

这里值得指出的是对于不同的组织，看似同样的能力，定位差异可能是巨大的。比如前面提到的大型商业银行，对于云能力的定位很可能是自有定制化的私有云共享经济建模问题，而小型金融机构可能就采用通用化的公有云服务。显而易见，这种差异也会影响对应团队的定义。

（Wardley Mapping示例，来源于官方介绍：）

基于这样一个坐标系，我们就能够把针对团队拓扑划分出的团队放入到地图中。每个团队必然是对外提供某种能力的，而能力之间的关联就产生团队之间的交互。

让我们用一个案例来展示如何结合团队拓扑和Wardley Mapping，最终通过在研发团队内部组织结构的划分来明确技术架构。

案例：面对元宇宙的未来，“买Ta”公司提供一个在线协同办公的平台，希望能够面向未来发展，梳理和规划该平台产品的核心力量 —— 研发团队。目前平台的核心功能如下：

研发团队过去几年已经采纳了领域驱动设计DDD的一些核心理念和方法，针对系统的复杂性进行了领域的识别和一定的限界上下文（Bonded Context）划分，并根据这些划分来确定了对口的敏捷团队。主要领域及BC划分如下图。

（案例：在线协同办公平台初步领域建模，蓝色圆圈表示限界上下文BC）

目前主要痛点是针对“模板库领域”的具体技术落地。模板目前类型繁多，由于工作量的原因，模板团队已经50+人规模，效率显著下降。按照敏捷价值驱动的想法，也划分成了矢量模板（如泳道图）、多媒体模板（如视频剪辑）和3D模板三个开发小团队，但小团队之间沟通非常频繁，抱怨很多。

团队的技术架构师们讨论和识别了模板之间可复用的模块，希望能够开展重构，强化整个系统的组件化设计，但这样的重构工作被需求开发工作挤压，一直都没能落地。

面对越来越低下的效能，团队领导让我们来为模板库领域的技术落地建立技术架构的团队结构，从而能够推动该领域的技术架构优化。下图是针对目标技术架构梳理的组织建模结果。

（“模板库领域”的组织建模结果展示，形成针对该领域的“技术架构地图”，除了三类型模板各自一个团队外，完成了“模板市场”和“模板工厂”的平台和组件团队建模。）

上面的建模结果形成了5个小团队：

这样的团队结构明确了我们针对该领域建模的技术架构，其中“模板工厂”存在一定不确定性，是否能够真正成功有待验证，所以在Wardley Map中也放到了相对靠初创的位置。“模板市场”应该说是现在典型前、后端分离架构的标准配置，确定性较高，由此也直接定位为平台团队。

在这样的团队建模下，相应的技术架构治理要点也变得逐步清晰，比如：

我们利用了Wardley Mapping完成了针对团队结构的组织建模，形成了面向逆康威定律的“技术架构地图”，从团队结构视角来展现了技术模块的组合。当然各个模块内部的具体技术实现，比如“模板市场”采用Vue.js还是React，这样的实施决策我们可以相信对应的实施团队来评估。

随着云原生和微服务架构逐渐成熟，各种配套和支撑的工具框架越来越完善，研发团队未来必然更加关注建模本身，而不必被服务路由、监控日志等基础琐事分心。由此也要求我们的技术架构师们更加关注团队的划分，更多考虑逆康威定律的实现落地。

技术架构的动态治理

开篇提到为了保证大家能够思考架构的演进，我们希望把“时间”纳入架构治理的一个重要维度。利用团队拓扑建立基于团队划分的技术架构地图后，坚持做好动态治理就是关键的下一步，否则我们又会回到过去“画图很美好、现实很残酷”的老路上。

强调组织建模，从团队结构入手的一个好处是缩短了感知闭环。从团队的视角观察技术架构中的“坏味道”更加直接，比如团队实现一个需求需要修改多个模块，定位一个改动需要花非常多的时间，这些可能就说明我们的技术架构存在值得去分析的问题了。

而如果我们有一些技术架构方面的改进需要落地，调整团队结构也是最显式的意图传递，比如上一个案例中，成立了“模板工厂”团队，就能够让大家理解我们技术架构上调整的意图。而相关的团队也能够名正言顺地开展工作，并帮助其他团队快速理解与之合作的目的。

延续上面的案例，让我们一起来看看利用这样的地图如何进行技术架构的动态治理。

进展一：经过一段时间的尝试，“模板工厂”小组形成了重构的套路，并且已经有3个公共模块被提炼出来，形成了内部的复用。最近完成了2个模块的代码主干合入和上线。公共模块目前通过SDK的方式提供给各个模板团队使用，分析识别出了额外的2个模块待重构。

三个模板团队反应对于采用新的SDK开发还不是很适应，已经提炼出来的第三个模块涉及到较大的代码重构工作量，目前还没有时间进行采纳。

根据这样的情况，我们应该及时对“模板工厂”团队的工作定位进行改变，由之前的面向模块化复用所采用的复杂子系统定位，转向帮助模板团队采纳新组件、推动各模板团队提升自身架构模块化的赋能团队。

（基于进展一带来的团队结构调整，“模板工厂”成为一个赋能团队，和三个模板团队的合作也采用“促进”模式，从而明确了团队工作职责和合作模式的转变。）

进展二：为了活跃用户社区，产品经理希望能够让用户自定义模板，形成真正的模板市场，由此作为抓手来激活用户之间的线上交流，甚至未来将模板作为艺术品进行NFT交易。

这个想法经过初步的价值建模得到了公司高层的支持。业务和研发团队联合进行了领域建模分析，在模板管理方面的领域模型改动较小，业务功能上允许用户进行多媒体和矢量模板的自定义（3D模板暂时不开放）。

技术团队经过分析，认为虽然模板的类型及数据结构未发生变化，但从业务连续性的视角，仍然希望能够将用户自定义的模板隔离开来。由此产生了下图的团队结构变化。

（基于用户定义模板组建了一个复杂子系统团队来进行专项开发，考虑到针对多媒体和矢量模板数据结构上的一致性，需要跟这两个相关团队紧密协作。成立复杂子系统团队也是希望明确阶段性的架构隔离，成熟后有可能进行团队的合并。）

团队拓扑全球社区也给出了结合Wardley Mapping类似的应用案例，感兴趣的读者可以参考英国运动服饰零售商店Footasylum的应用案例：

组织建模小结

组织建模的核心逻辑是针对软件产品和系统内部架构上的逆康威定律，即我们希望通过保持组织内部的灵活性来迎战持续变化的外部需求，从而能够持续增量交付高质量的产品或系统。在技术架构层面，团队结构和技术架构是直接的映射关系，相互作用在日常开发工作中立竿见影。

由此，在技术架构层面的建模工作中，我们提出了两大视角的转换：

管理标的物的转换，从过去系统内部的技术模块到现在研发组织中的团队，促使我们真正地思考如何能够从团队定义和协作模式上保证技术架构的落地；

架构演进考量的转换，从过去考虑技术模块的改变转换为考虑团队结构的改变，促使我们思考合理的认知负荷的分配，为团队的高效能运作奠定基础。

我们意识到这种视角的转换，对于已经习惯于划分各个技术模块的架构师及团队来说是一种挑战。但我们希望大家能够知行合一，真正将架构的演进贯彻到日常的架构治理工作中去。而我们这里提出的组织建模，无疑是帮助大家明确演进过程的一种方法。即使短期视角转换困难，也应该在读完此文后，开始在技术架构设计阶段引入基于团队结构的组织建模，并且在出现架构问题时，多一点团队结构合理性的考虑。

最后，利用这套方法进行的组织建模也是可以“递进”的，在大型研发组织层面，我们可能首先划分出的是百人规模的团队组合，比如一个技术中台部门；然后再就每个部门（团队）进一步地小团队划分，比如技术中台部门中也有数据一致性服务的业务流团队和数据备份的平台团队，划分所采用的元方法是类同的。

成就一亿技术人

手机浏览，点击图片保存二维码到相册，然后打开微信扫一扫选择本二维码图片就可以进入，电脑端微信“扫一扫”二维码，进入找聊天搭子平台，里面有找饭搭子、找对象、找陪伴服务等等