重新发现业务架构：银行数字化转型经验与方法分析_架构_dbaplus社群

FinOps有望降低企业50%+的云成本！了解详情 



 写点什么

本文根据付晓岩老师在〖2020 Gdevops 全球敏捷运维峰会〗现场演讲内容整理而成。

大家好，我是付晓岩，非常感谢 Gdevops 峰会的邀请。我今天跟大家分享的题目是《重新发现业务架构》。这个题目里面有两层含义：第一是业务架构，包括业务架构的概念、核心逻辑、作用。第二是重新发现。业务架构的概念是上个世纪的，但最近几年在企业级实践里发现了业务架构的一些作用，所以今天我们又重新看待它的价值。

一、银行的企业架构实践

1、某国有大行的企业架构实践过程

下图是国内某大型商业银行的企业架构实践，是当年该行推进“新一代核心系统转型工程”的逻辑。从发展愿景出发，把该行的发展战略导入到整个过程里面，从战略开始到设计业务架构，到业务架构再到驱动 IT 架构，直至把它实现，是一个很标准的企业架构过程。

这个过程里该行首先梳理了自身的六条价值链，包括产品设计、营销支持、产品运营、业务支持、风险控制、决策与报告，相当于梳理了金融这个行业的价值创造过程。

在这个大的价值创造过程下，结合发展目标和行里的愿景，确认我们要在哪些业务方向上有突破有变化。当时梳理了 26 个业务方向，顺着这 26 个方向，该行为实现落地继续往下做更细的数据，梳理了 102 个转型举措，这 102 个转型举措再往下分解战略型的业务需求，分解了 2000 多项，这样才能把贴在墙上的战略变成一个可以跟业务落地的过程，这是很多企业做战略做得不好的地方，没有做很详细的分解。

光有分解还不够，还得有模型化的东西。根据业务现状先做一个现状的架构，然后导入战略，变成目标架构，去做一个推动。当时主要有四个模型：流程模型、数据模型、产品模型、体验模型。这个就是该行做转型时的主要架构，主要分为两部分，一部分是现状，就是导入目标前业务情况，然后把目标导入后，产生我们新的应用需求。

在梳理的时候做了很多工作，流程模型，三级活动这一部分曾经把最初梳理的 10000 多个模型活动标准化最终整合为 900 多个，所以这部分的梳理力度很大，包括建立了全行第一个数据统一模型，这个统一级的数据模型在以前银行业应该是没有的，产品模型更是行业首创。

通过这个模型，我们梳理出来以后融入业务组件的设计，总结成 114 个业务组件，相当于行里 2000 多个战略能力需求分布在这 114 个大框里面，每一个框都是企业级公用的，不是只给部门服务的。顺着这种业务架构再往下去做应用架构和技术架构，这个过程其实花了六年半的时间。以上信息均来自于该行已经公开发布的文章资料，大家可以在网上查阅更多的细节情况，尤其是该行信息总监金磐石先生的文章。

2、国内四大行的企业架构实践

是不是只有该行在实践呢？其实不是，四大行在这方面都有各自的探索。最早进行探索的是农行，像流程建模有三级、四级、五级，农行最先探索的是三级活动，农行近年可能又会启动新的工程，去把业务架构做得更完整。建行 2010 年底到 2017 年 6 月份，六年半的时间投入 9500 人次完成这个企业工程。工行是在建行之后进行的，工行的企业架构在 2019 年发布，它宣称自己有 2300 多个任务组件，含 28 个业务领域，今年又进一步增加到 3500 多个任务，63 个业务领域。中行 2018 年也宣称在进行自己的企业架构探索，但具体成果还未见对外发布。

除了四大行以外，现在其他股份制商业银行，包括一些城商行也在进行自己的数字化转型和企业规划，但是做的时候可能不一定做业务架构，但是这一部分其实在工程上来讲是个误区，应该先把业务理清楚才能规划 IT 这边。

二、互联网企业在同一时期的业务架构探索

同一时期，互联网企业在做中台。下图这条历史线是阿里巴巴集团做中台的过程，2008 年就有一个中台库，2015 年设置中台战略，2018 年变成一把手工程拥有资源，取得一定实施效果后开始对市场进行宣传。

下图就是网上随处可见的中台架构图，这种更多的像个概念图，因为所有的视角都混在里面。做架构我们知道从 1987 年 Zachman 框架开始，强调架构要多个视角并行，每个视角有每个视角的图，是一套架构而不是一个单一架构。但是经常我们看到的概念都是混在一起的，业务、应用、技术架构都在一张图上，所以大家经常不清楚架构应该怎么做。

2018 年发布完中台之后阿里巴巴也没有停滞，因为企业架构这种东西永远在路上。2020 年年中他们发布了一个新的钉云一体的东西，最近他们内部还在继续讨论。所以在同一个时期里面，不管是传统企业还是互联网企业，都在尝试把自己企业内部的力量整合起来，也就是说都在探索企业架构，不管你是有意或无意地用到过这个概念。

之所以今天会用“重新发现”这个词，是因为之前我跟互联网的一些朋友聊天，他们说其实有的时候事情做得确实很快，但是完成之后才发现自己解决的问题在别的行业早解决过了，所以做企业架构的时候，多研究过去的案例或者方法论，可能会省下一些探路的时间，不是每条路都需要亲身去探索。

三、业务架构在两个不同阵营的实践

传统企业与互联网企业在探索企业架构的时候有什么共同点？这个共同点我觉得就是突然都很强调业务架构的作用。“新一代核心系统转型工程”期间培训的时候，我们多次把业务架构的重要性喊的很高，但是喊是在内部喊，没有对外宣传。这整个过程大家当时看得到都是由业务架构驱动的。互联网企业也一样，在 2018 年阿里巴巴发布中台的时候也宣称业务架构在整个中台的规划过程里面作用巨大。

这些作用体现在哪里呢？

1、业务架构的标准化

我们传统企业做的时候，也希望找到可以被公用的能力，减少重复建设，所以我们也会去做流程或者数据的标准化，通过标准化的方式来去重。中台做的也是这件事，沉降公用能力。

要沉降怎么判断标准是一致的？很难，所以有时候一说到做软件，做企业工程，一提标准化，很多人就会说标准化不太可能，但如果标准化不可能的话，这个企业永远都不会有可复用的东西，你也根本识别不出什么东西是一样的，所以业务架构在里面起到的作用很大，其关键就是对标准化的努力。

2、业务架构的参数化

除了标准化之外还有参数化。参数化在单体应用的时候大家已经在追求了，我们希望一个系统的功能调整很多可以通过参数配置完成，而不是总去改系统，这块参数其实在传统企业这边体现在了产品参数上，在互联网企业也一样，也有很多的参数可以配置。

3、业务架构的装配化

除了参数化之外其实最难的是装配化，说能力复用，不光是调用一下就解决问题了。产品发布的时候我希望能够把已有的 IT 资产用一个模板装配的方式让它快速产生一个新的产品，这个任务在前边案例的实践中是由产品模型来承担的，按照该行公开发布的数据，它有 201 个基础产品，也就是有 201 个产品的基础模板，这 201 个基础模板支持 20000 多个金融产品的配置，包括它的装配。

互联网企业也有类似的东西，把业务能力沉降下来之后变成这个模板，包括业务模板、产品模板，再通过配置信息进行装配。

下图右边是 2018 年毗卢老师做阿里中台演讲时发布的一张图。这是我个人在介绍中台的时候比较愿意用的图，因为这个图体现了做中台或者做业务架构时抽象的方向。比对一下双方之间的方向，我们发现两个阵营都很强调业务架构的作用，但是做法截然不同，差别很大，但是这也意味着大家在探索这个问题时，自由度很高，两个阵营的东西都可以用，不必死守一个，方法论是一个非常有弹性、非常灵活的东西。

四、企业级业务架构概念

接下来讲讲业务架构的定义，根据我自身经验来看，业务架构是为了把企业的战略落地，对企业的能力进行整体规划，再把它传导给 IT 实现这一侧的结构化分析方法，所以它是个分析方法，目标是落地战略，它的特点是要做整体规划和结构化的表达，所以这也是为什么在企业架构里模型变得很重要。

1、业务架构的重要价值

业务架构其实有一个很重要的价值。以往我们说战略指导业务，但是去发现战略经常跟具体业务对不上，如果能够把战略像前边案例中做能力分解那样细拆，然后再去把它跟现有的流程对接到一起，看流程里面有哪些东西需要调整、增补或者是已经过时的需要删除。这种情况下，你才能把每一个需要的战略能力落实到一个具体承担它的活动或者任务上，这样它才是可落地的，才叫战略落地。战略落地不是一个决心或者是一股蛮力，而是有结构化的方法，这也是业务架构在业务这一侧能够独立发挥作用的一个关键因素。

理清楚之后，说清楚战略跟业务的关系才能转化成需求，因为很多 IT 人不关心战略。其实这也不怨 IT 人，因为好多业务人也看不懂战略。只有通过这种方式才能让业务和 IT 两边都能看清战略，才能把这个三角形串起来，来解决这个衔接的问题，这件事对于业务和技术都是同样重要的。

2、业务架构的一般设计过程

说到业务架构的一般设计过程，首先是战略设计，战略设计之后调整组织结构。如果组织结构不用动的话，相信大部分时候战略也不用动。战略调整了组织结构之后，如果组织结构调得不好，肯定会影响战略的落实。这两部分总体来讲对业务架构设计是约束条件，因为这两部分都是企业领导的事情，架构师能提建议，但是下决定的人是领导，领导通过以后才会把这个对应到现有的业务分析和组件设置。

3、业务架构的整体逻辑

业务架构设计最终是为了实现战略和组织设计，这个就是业务架构的整体逻辑。前面已介绍的例子也是从价值链分解开始，为什么要分解价值链？其实是为了给所有领域搞业务抽象建立统一的标尺，而这个标尺一定是围绕着企业的价值创造过程。这种情况下你可以把各个领域的活动分到各个价值链下面，然后进行比对，去找有哪些任务是可以公用的。这里光从流程上判断并不准确，还需把数据也加在一起，流程跟数据加在一起才是标准化的东西。

我个人认为以后架构中业务架构和数据架构应该并成为一个架构。上图从业务的视角，从上到下，把价值创造过程到活动分解开来，从下到上，则是技术视角，可以看到功能是如何组成业务形态的，它能够为业务和技术之间的沟通建立一个共同的思维模式，建立共同语言。

4、企业能力地图构建和未来之路

企业能力地图在很多地方已经开始提了，能力地图是我们将来演进的一个基础。企业真正向数字化演进，需要用历史和未来的视角判断战略，再把战略分解到价值链，把价值链再对应到业务架构，这样才是真正把未来战略落地的一个过程，这个也是我在《银行数字化转型》一书中所采用的逻辑，因为这块是每个企业要自己建的。

5、需求侧革命的意义

把业务架构推到业务侧用的话，让业务人员能掌握业务架构思维的话，对我们提升软件开发的效果非常有用。

我们用供求曲线来看，不管技术这一侧往外推多远，其实在需求这一侧，需求曲线不上升的话，光是生产速度快、开发更多的软件，质量并不能上去。这部分有很多可能产生一些技术债，比如太着急上线了，想得也不清楚，结构上也不太理想，最后上线半年之后或者几个月之后又推倒重来，实际上只是多干活了。如果业务思维这一侧更好的结构化，大家能够很好的看这个问题，不是单单追求快，两条曲线同时上升开发效能才会上去。

五、两个阵营共同的难题：业务架构师的培养

传统企业和互联网企业这两个阵营里都反映出了一个问题，就是业务架构师很难培养，必须得自己培养，培养的时候要注意这些方面：

架构能力是核心，对于业务架构师来讲最重要的是架构能力，看清结构；
流程优化是抓手，业务架构需要经常跟业务打交道，流程优化能力有助于跟不部门更好地衔接；
建模能力是武器，因为最终要用模型来表达；
软件过程要了解，这样才能与 IT 之间良好衔接；
整体思维要牢记，因为要做的是企业级，企业级最大的特征是完整、横向拉通。

六、方法论研究：扩大舒适区

最后，鼓励大家多研究方法论，因为方法论是帮你把一些偶然经验变成一种可重复实现的必然成功的路径。方法论是最普惠的，方法论能教给每一个人，而且方法论也没法申请专利，大家都能免费用，持续研究方法论才能持续帮助你去掌握自己企业的方法和结构，也能够帮助你辨别谁说的东西对，谁说的东西不对，而不是跟风走。研究方法论我认为比较好的方式是扩大舒适区，选一个方法论做主线，持续吸收别人的优点，而不要频繁切换赛道，频繁切换赛道相当于自废武功。