从业务架构视角聊聊大型商业银行的转型实践

随着云计算、大数据、区块链和AI以及移动互联等新一代信息技术的发展，企业数字化转型加速。市场在变，需求也在变，面对高度创新和充满不确定性的敏态业务，为快速交付高质量的软件产品或服务，企业需要有更好的业务架构设计，去适应不同阶段的业务特性。

何为业务架构设计？企业的业务架构设计需要考虑哪些因素？业务架构设计的难点和挑战是什么？企业应该如何权衡？…

面对这些问题，InfoQ记者采访了 QCon 全球软件开发大会 2020（北京站）的讲师、《企业级业务架构设计：方法论与实践》一书作者——建信金融科技有限责任公司付晓岩老师，请他从企业级业务架构设计实践者的视角聊聊这些问题。

2000年大学毕业后，付晓岩就加入建设银行。从业20年，12年在业务领域，8年在IT领域，他的脚步遍及支行、分行、总行、子公司等建行内部各层级机构。进入IT领域后，付晓岩近乎全程经历了建设银行规模宏大的企业级转型项目，并在项目中得到历练，从而成长为一名资深的企业级业务架构师。

业务与IT之间的桥梁

IT设计的真正目标是实现企业的价值。业务和技术应该是统一的、一体的，它们都是企业的有机组成部分。

在付晓岩看来，业务架构是业务与IT之间的桥梁。不管规模大小，企业都是一个整体，其生存、发展都依赖于企业形成内外部合力的能力，而这一能力的形成有赖于构建适宜其战略执行的企业架构（EA，Enterprise Architecture）。

他认为，一个好的架构有利于企业战略的执行，尤其是数字化转型。数字化转型是业务与技术的深度融合，而融合需要机制，需要二者建立有效连接，业务架构正是这种连接方式。

“战略通过业务架构分解到业务流程，并将业务能力体系化、结构化地分解到企业的各个业务部分，再转化为IT需求，通过与业务目标匹配的IT架构完成技术实现，将企业的战略和能力、业务和技术有机串联起来，构成一个协同整体。这就是业务架构乃至企业架构的使命。“付晓岩表示。

银行业务架构的演变

从自己的经历出发，付晓岩阐述了银行业务架构的演进。

相比其他行业，银行是信息化起步较早的。并且，大型银行组织结构复杂、技术开发投入高、应用范围大，因此，大型银行在架构发展历程上很有代表性。

以国内银行为例，其在架构方面的发展历程如下：

国内银行的架构演进趋势

80年代：分散架构

20世纪80年代后半期，银行开始引入主机系统，这时构建的业务系统“高度”分散。每个地级市都有自己的业务系统，不同城市间的业务无法联通。

以一笔汇款业务为例，现在是实时转账、零级清算、秒级到账，而过去是多级清算。跨地区汇款，从一个城市的网点到自己的市分行，市分行到省分行，省分行到总行，总行到目标地的省分行，省分行到市分行，市分行到网点。可想而知，这种方式效率极低。

90年代：大集中架构

90年代末，随着计算机性能的提升和网络的发展，银行对数据集中的需求越来越强烈，因为先有数据集中才能实现业务集中。因此，银行的大集中架构拉开帷幕。

付晓岩表示，“大集中可以构建全行统一的业务系统，这对业务效率的提升是不言而喻的，但与此同时带来的问题逐渐显露，即‘竖井式’开发、烟囱林立的问题。”

2011年左右：企业级架构

据付晓岩介绍，建行在2011年开始进行企业级转型，设计全行统一的企业级架构，包括企业级业务架构和7层12P的企业级系统架构。

2017年，整个工程结束，建行内部一体化初步完成。

数字化时代：开放式架构

不过，架构的演进不会就此“打住”，内部统一后，银行更重要的是适应面向数字化时代的开放与融合要求，深度参与到生态建设中。这一阶段是开放式架构，真正从社会分工、生态分工的角度，结合生态伙伴、客户情况，综合分析架构解决方案。其设想如下图所示：

开放式架构理念演示图

付晓岩指出：数字社会必定是一个与今日大不相同的“新时代”，无论是企业，还是个人，所有参与者都将迎来一个转型过程。对企业而言，架构”新时代“的到来是注定的，这个”新时代“一定是业务架构与技术架构、业务与技术深度融合的时代。

银行业务架构设计和实践

考虑因素

第一，目标的匹配性

企业需要清晰了解目标是什么？要解决的问题是什么？架构设计不是为了概念而设计，企业不是为了做业务架构而做业务架构，也不是为了上“中台”而上“中台”，都是为了解决问题。

付晓岩表示，“目的与手段要相匹配，目标的大小决定了业务架构设计的力度。”

第二，资源的适配性

企业级业务架构设计不仅需要投入业务和技术人员，而且还需要有经验的业务架构师进行指导以逐步培养公司自身的业务架构师。“由于业务架构领域还比较‘小众’，有经验的企业级业务架构师很少，更多的是技术架构师。像一些‘失败’的中台项目一样，没有与目标匹配的资源也是项目成败的关键。”他表示。

当然，即使有了业务架构师，如果没有足够数量的企业业务和技术人员配合，业务架构师也不能编出“架构”来。

第三，时间的适配性

企业级业务架构设计不能也不该很快，这是对企业自身的深入解读和对未来的严肃规划。它需要一定的时间投入，如果抱着“吃快餐”的心态，那项目质量很难保证。

虽然架构设计不是一次搞定，需要演化，但是要为“打地基”投入合理时间。

第四，耐力的匹配性

这里的”耐力“指的是坚持以企业级业务架构为核心，长期驱动企业业务管理、IT管理的耐力。

付晓岩认为，企业级业务架构是一种“秩序”，而“秩序”的维护需要耐力，如果没有坚持的定力，那一次性的成功，很可能换不回企业的投入。企业需要的是维持持久的竞争力，也自然需要耐力上的付出。

业务架构设计的三个阶段

以银行为例，其在进行业务架构设计中一般有几个阶段。

首先，建立明确的企业级业务架构设计工程项目，并任命强有力的行级领导进行统一管控，将相关业务部门、技术部门全部拉入工程项目，以确保决策能力和执行能力。无论国内还是国外，企业级项目都是“管理者工程”。

其次，进入项目过程，这时要明确战略目标，即银行针对多少年的战略目标进行架构设计，确定战略目标是什么，战略目标对应的战略能力有多少，目标越大，需要分解的能力自然越多。

然后，形成现状模型。将银行现有的业务流程模型化、结构化，通过统一的企业价值链进行分类、整合、标准化，并将战略能力分解到现状模型中，将模型与战略对齐，识别需要改变的业务流程，这就产生目标模型。

付晓岩指出，尽可能在架构设计过程中，将全行统一的数据模型一并设计出来，然后结合数据模型和流程模型，提升标准化程度，设计出业务组件。最终形成包括战略、战略能力、流程模型、数据模型、组件模型的企业级业务架构。

业务架构设计虽然不求快，但也要注意合理控制时间，“一到两年是比较合适的首次建模周期”。

建行业务架构设计实践：六年磨一剑

2011年到2017年，建行进行的“新一代核心业务系统”建设项目，正是通过企业级业务架构设计驱动的，也被称为“六年磨一剑”。

整个实践，先从战略定位开始，分析建行的十二五、十三五规划，确定全行的整体战略目标。并且，还将战略目标分解为更细的战略能力举措和更细粒度的战略能力需求，“其目的是为了让战略落地具有更清晰、操作性更强的要求”。

其次，进入现状建模和目标建模阶段。这是将建行实际的业务和改进举措与战略对齐的过程。经过这样的模型设计过程，包括价值链、流程模型、数据模型、产品模型、用户体验模型和业务组件在内的整体业务架构设计和架构资产即形成。

据悉，总体架构设计大约花费2年时间，这与建行庞大的体量和业务复杂度有直接关系。同步完成的还有适配整体业务要求的技术架构，即7层12P的方案。

然后，开始根据企业级业务架构和技术架构进行具体项目落地。整个企业级转型总体分为三期，每期也有不同的小周期，由转型项目的PMO统一管控进度。期间，还进行了海外建模，即实现全球架构一体化的海外模型设计及海外实施。

2017年，建行公开宣布工程结束。据公开信息介绍，实际落地114个业务组件、整合设计900余个业务活动、标准化4500余个任务、3000余个数据实体、150余个基础产品和1万余个可售产品，“在世界银行领域，这是首次完成如此大范围和深度的企业级业务架构设计与实施”。

业务架构设计的难点

技术难点：标准化

从技术层面讲，业务架构设计最大的难点是标准化。标准化是判断服务异同和颗粒度的重要依据，这是各类架构设计中的难题。建模离不开标准化过程，做企业级模型要横向对比企业所有业务领域，以期望在设计上实现“以更少支持更多”，并实现快速的灵活响应和减少重复开发这两个目标。

业务架构模型的标准化包括数据标准化、任务标准化两部分，这两者相辅相成，通过数据间的比较可以更好地进行任务标准化，而通过与任务的结合也能更好地判断数据定义是否准确、数据标准化是否到位。

除了技术挑战，还有诸多工程难点。

工程难点1：捷径难寻

了解DDD（领域驱动设计）的人可能知道，DDD对企业级不抱太大希望，认为企业级的建设路径只能是一个领域一个领域的不断尝试融合，无法通过自上向下的规划产生。

在付晓岩看来，金融领域恰恰是一个很不“专业”的专业，里面的东西五花八门，看似都在一个领域，实则“千差万别”，各类业务的共性在于客户（同一群客户），围绕客户共建一个账户体系。换句话说，如果自上向下看，客户和账务应该是企业级的，而其他部分，需要一个领域一个领域的研究，这也是建模和标准化的难点。

因此，企业架构建设的难度跟企业所在行业的特点有直接关系。没有一个通用的企业级业务模型可以随便套，“阿里的业务架构套不到银行头上，银行的业务架构也套不到阿里头上”，甚至一个行业内，企业跟企业间内部特点的差别，也会决定企业架构建设路径和结果的不同。没有简单复制的模式能帮你快速切换到企业级，“自己的路只能自己走”。

但是，需要所有从业人员共同探索的，也恰恰是如何构建成熟的行业级模型，这是未来实现大规模软件生产的关键。

工程难点2：文化难建

多数情况下，企业级不是一个单纯的技术问题，这让技术人员非常为难，因为这根本不在其能力范围内。如果是一个业务种类繁多、部门庞杂、等级森严的传统企业，建企业级相当于对部门边界、协同关系的重新界定，它对企业文化的依赖和改变都很强。

工程难点3：权责难定

在组织中，一件事情能做好，前提是做事的人权责匹配。但是，架构定位的困难在于，权力太小，不足以维护企业级；权力过大，又会发展成新的部门化组织，可能会导致架构决策行为方式出现“僵化”。建立合适的集体决策机制很重要。

工程难点4：长志难立

企业级（项目）的长期坚持是件难事，它的放弃和崩坏不一定是是架构组织撤销、机制停掉这么激烈的动作，而是各种“畏难情绪”、“客观原因”导致的缓慢的无序，它是一个个需求的分配、落地的偏离堆积产生的。并且，“破窗效应”对它的影响也很明显。总之，一定不要搞“一次性”的企业级工程。

业务架构设计中的trade-off

在业务架构设计中，企业除了“直面”挑战，还要权衡诸多事宜。付晓岩认为，业务架构设计是个迭代的过程，要允许反复和调整，不能武断，没有耐心。

首先，不能允许简单的“拍”结构。架构师必须具有开放性，保持谦虚。架构师是“中心”，但不要总把“权威”看得太重，架构是企业整体资产。从某种角度说，企业做架构正是为摆脱对特定架构师的“单点依赖”，让架构工作能保持“业务连续性”。因此，架构设计要保持这种谦逊，这样才能让更好的设计思路进入设计师的视野，进入设计方案。

其次，允许什么样的架构调整。

1.查漏补缺。

项目有周期，每个环节都有一定时限。除首次做企业级转型外，业务架构设计是很重要却又不能被分配太多时间的环节。因此，业务架构师必须在尽可能短的时间给出覆盖度尽可能完整的架构方案。但是，时间越短、信息越少，就越可能出现疏漏。在细化阶段发现问题很正常，自然调整就好。

2.发现更好

在实施阶段，由于输入的细节通常比业务架构设计阶段更多，并且不排除在实施阶段发现更好的做法，这样的改良可以重写到业务架构中，由此带来的业务架构调整是有益的。

3.现实妥协

架构设计经常不仅仅只有一个可行方案。架构师手里永远准备着两套方案，随时可以抛弃其中一套。比如，原本设计时有两个方案可以选择，在为C领域做业务架构设计时，A领域和B领域都有可以采用的实现能力。A领域的业务性质与C领域更为接近，于是架构设计时选择A领域，但实际推进项目时，负责A领域的项目组由于客观条件限制，无法按时实现，只好再转到B领域，这两个方案基本等价，但是架构和模型上必须要做一定的调整，这是受现实条件制约的。

4.错误修正

对于架构设计错误，架构师要深入了解错误原因，总结原因，反省和提升自我，“好的架构师都是时间和项目铸就的”。如果一名架构师经常出现此类问题，就必须考虑对其进行调整，或到项目组重新锻炼，或是不再让其担任架构职责；如果是整个架构师团队经常出现此类问题，很可能是工作机制的原因。总之，集体问题与个体问题不同，需要区别对待。

再次，不允许明显违反既有规则的调整。

以客户统一视图需求为例，这是典型的跨领域需求，但又具有一定的领域特性。因为金融行业客户可能同时在多个领域发生业务，但每个业务线从自己的领域出发，应用客户视图时不一定要看所有内容。这就相当于在一个统一的数据基础上分领域定制，这样的需求既可以由客户管理组件实现，又能由负责数据仓库、数据主题的项目组实现，无论哪种实现，本质上都是通过数据仓库加工。

但是，分工一旦形成，就不要随意调整。如果既定是由客户组件做，特别是客户管理组件已经实现部分功能时，就不应该允许客户管理组件再以各种理由拒绝后续需求，把其他需求交给数据加工的项目组去做，这样会导致架构混乱和决策原则的不一致。不要轻易推翻已经成为事实的判断原则，要通过事实建立共识，建立规则。

关于企业开展业务架构设计的6点思考

关于企业开展业务架构设计工作的思考，付晓岩表示，不想泛泛而谈，先设定前提条件。如今正在进入时代转型的“阵痛期”，我们将成为直面转型的一代人，终将在一个不那么长的时间里，面对真正的“数字化时代”。以此为出发点，我们应做好几点：

1.培养业务架构师

业务架构目前是人设计的，而非AI自动设计，因此业务架构师的培养是第一位的。业务架构设计需要长期的实践，具备良好的结构化思维，需要对方法的深入了解和工程上下游的充分了解，而非灵机一动突然悟道，需要“慢功夫”。

2.建立架构之桥

业务架构位于业务和技术的中央，没有经过企业级设计的“地形地貌”，会逐渐演变成“迷宫”，充斥着各种鲜为人知、容易迷路的“捷径”。如果建设了能支持从业务模式到技术实现完整关联、逐层展示的业务架构，企业就会有一张清晰的地图来进行“导航”，从而实现对业务问题的快速解决、对技术的合理应用，这是非常重要的价值，并且是有效连接二者、实现深度融合的方式。

3.转变业务思维模式

数字化时代，软件是最核心的生产力，各种业务需求都将主要依靠软件的改良实现，企业的核心竞争力来自于业务与技术的融合能力，这意味着从业者的底层思维逻辑需要“刷新”，与这种生产环境最为匹配的显然是结构化思维能力，应当考虑通过业务架构设计方法和任务持续提升业务人员的结构化思维能力。

4.转变软件生产方式

技术人员要能结构化地看待业务构成与技术实现的关系，从而更好地将业务分解成合适的“零件”，这是在技术人员原有结构化思维方式上的一种深化。对技术人员而言，还意味着主动去接受标准化的“约束”，从个体化的改进软件向公用化的改进“标准”发展，逐步实践以标准化组件支持企业商业模式的构建。

5.加强架构思维锻炼

在付晓岩看来，架构设计的四大思维支柱包括整体思维、洞察能力、演进思维和开放思维。架构设计应坚持从整体看问题，而非执着于局部细节；要坚持通过深入交流来获得对业务的洞察，而非仅停留在需求文档或者少数人员的转述，最好有来自亲身参与获得的洞察；不要“唯快不破”，要坚持循序渐进，虽然要以数字化转型为持久方向，但也不能“拔苗助长”；要坚持方法间的优势互补，坚持设计理念和方案的开放性，要面向开放的生态设计架构。这些原则既适用于架构师个人，也适用于企业管理。

6.构建环境

无论是方法论，还是架构师，作用的发挥都离不开企业环境。如果企业没有配套环境，没有合适的体制机制保障方法论的落地，那就没有一种方法论能给企业带来改变和优势。架构师和企业是互相成就的，二者的同时成功也促进了方法论的发展。

更多架构演进相关实例请持续关注QCon北京2020。一线技术大咖助你一臂之力，轻松应对高度创新和充满不确定性的敏态业务，快速交付高质量的软件产品和服务。