如何构建企业架构和研发效能的增长飞轮

本文作者：李腾、夏思雨

企业架构研究的是系统架构，包括业务和技术组件以及组件对象之间的关系。研发效能治理的对象是开发和运维过程，看起来和企业架构并没有直接的关系，在软件企业里往往也是属于不同部门的职责范围。但在实际的研发效能和架构治理的研究过程中，我们看到二者在不同的阶段总是在不断地产生碰撞，例如前阵子我们的一项研究就是，根据代码提交记录分析研发态团队结构和系统架构的映射关系，也让我们对二者的关系本质重新进行了思考。

根据第一性原理进行梳理后，我们发现研发效能对应的问题域，本质上和企业架构要解决的问题殊途同归。管理者希望提升研发组织生产力时，必须同时协调好研发效能和企业架构的工作，任何单方面的努力都无法最终实现组织的能力提升。

1. 企业架构的三个分层

按照TOGAF的企业架构分层，第一层是业务架构，主要由业务人员根据产品侧的用户旅程进行设计，产出服务蓝图。第二层是应用架构（姑且把数据架构合并进来），在这一层，各种用户的操作和数据被聚合成应用组件，来支撑不同角色的业务交互，相关的质量属性需求在这一层也会被考虑，变成确定的质量要求指标。第三层是技术架构，负责落地相关的代码和中间件的具体设计，包括系统最终的部署方式。

小型项目三层架构的设计往往不是很明显，从业务到技术由一个或者两个人来承担全部的工作，缺少中间的应用架构过程。但对于大型复杂项目，或者大型企业的平台项目建设，应用架构的缺乏会导致研发过程失控，往往可能产生两种结果，要么陷入筒仓模式，产生浪费，对于数据的归集和统计带来不必要的困难，要么陷入复杂调用的大泥球，一个业务需求的变更会引起大量的修改，带来无法预测的风险。

2. 企业架构如何影响研发效能度量体系

我们服务过的公司，软件开发团队的规模基本都超过一千人，这些大型组织正在或者即将组建专门的工程效能团队。团队的职责主要包含研发效能度量，研发过程治理和研发赋能平台开发，也有的组织在现有的质量保证部门上进行了相关的职责扩展，将原先测试部门的守门员角色转变成治理和赋能的决策型角色。

在Thoughtworks2019年4月的技术雷达中提到了研发效能的四个关键度量指标，即前置时间，交付频率，失败率和失败恢复时间。现在大厂的工程效率部门，也在使用类似的指标，例如阿里使用的指标包括：持续发布能力，需求响应周期，交付吞吐量，过程质量和交付质量。我们可以看到，这些指标实际分为了两大类，一类主要和业务变更响应速度相关，例如前置时间和交付频率， 一类和系统可用性相关，例如失败率和故障恢复时间。

研发效能度量的目标之一，是为研发管理者提供决策依据。每一个企业，业务成熟度，组织成熟度，技术成熟度都各不相同，亟需在当前解决的问题也各不相同。因而，如何以四个关键度量指标为方向，结合企业架构的组件与关联关系，在研发流程的细分环节上选择恰当有效的度量指标，就成为研发效能度量体系的核心所在。

3. 借助研发效能度量指标评估架构设计

通过观察我们为多个客户制定的研发效能治理的度量体系，可以看到两类效能指标（效率和质量）实际上对应到企业架构的应用架构和技术架构两个层面。业务变更响应速度和系统可用性实际上反应了这两层架构应对变化的响应能力，这就能够帮助我们回答下面两个问题：

第一个问题：如何评价架构设计的好坏。一般性的回答往往是：好的架构要高内聚低耦合。但高内聚低耦合只是原则，如何反映到具体的设计上，尤其是如何宏观地反映到大型复杂系统的设计上，很少有人能说的清楚。在一两个代码片段上根据确定的上下文，相对比较容易作出判断，但在复杂系统中我们缺乏确定的上下文，做出判断就会变得困难。但研发效能指标给我们一个线索，应用架构设计的质量可以反映在业务变更响应速度的指标上，具体来说，因为业务需求变更引起的应用架构设计的变化，反映了企业是否拥有设计良好的应用架构。

第二个问题：如何设计恰如其分的技术架构？这个问题典型的答案是风险驱动模型。我们再看一下风险和系统事故的关系，发生的风险就是系统事故，而风险的预测和跟踪来自于以往的事故记录。研发效能指标中类似失败率和故障恢复时间这样的质量指标恰恰就对应了风险管理的实际记录。质量问题产生的典型场景，例如系统的性能和可用性，落点一般都在企业架构中的技术架构层，因此，效能指标可以很好地映射到系统技术架构设计的合理性，资源利用率低下的系统往往意味着技术架构的过度设计，可能存在冗余的资源或者研发成本的浪费；而事故频发系统的背后往往是在业务模块中四处打补丁，缺乏有效的技术架构设计。

4. 研发效能治理和架构治理的关系

回到本文的起点，在我们的研发组织内，研发效能治理和企业架构治理在通常情况下会是两个部门的职责范围，相关工作内容和方法也都有所不同。但在实际的工作过程中，二者以研发过程为中心，会产生大量交集，工作成果也是互相促进和制约。

举个例子来说明一下这种关系。对于应用架构，以写故事卡为例。写一张故事卡不难，难的是理顺卡和卡之间的关系，进而产出价值高，成本低的故事卡，同时在迭代内合理安排具有不同依赖关系的卡，最大程度并行，减少因为依赖关系导致的互相等待，达到迭代内最大的Throughput。实现这个过程需要对业务架构和应用架构有全面的理解，同时，架构师还需要创造力，发掘多种可行的方案，并在多个备选方案之间依据一定原则标准进行权衡和取舍。达到这一点，整体的业务响应速度就可以得到提升。

再以技术架构为例，一个常见的系统可用性问题是，第三方系统的临时失效导致的业务关键路径中断，整个系统核心业务停止服务，更严重的甚至引发雪崩。对于这种几乎一定会发生的情况，架构师应该根据关键任务在调用链路上设计相应的熔断措施，提供一定的降级服务能力，通过fast fail保护自身的可用性的同时借助DevOps手段快速恢复服务。这种可预期的风险导致的架构变更，我们一定会基于系统整体的技术架构进行设计，而不是在具体的故事卡内部实现。而如何配置具体服务的熔断参数，我们往往需要通过系统可用性指标度量，通过技术架构持续迭代系统可用性指标的采集和分析，从而实现整个系统的可用性提升。

我们可以看到，研发效能的数据趋势可以体现架构治理活动的改进是否有效，有效的架构治理措施会带来架构成熟度的升级，从而影响整个研发效能度量指标的持续改善。架构治理作为研发效能提升的方向之一，帮助研发效能治理构成了软件工程领域持续改进的一个闭环，我们需要帮助二者连接，形成持续的正向反馈，从而构建研发生产力持续提升的飞轮。