《大型商业银行的业架构转型实践》由会员分享，可在线阅读，更多相关《大型商业银行的业架构转型实践（15页珍藏版）》请在金锄头文库上搜索。
1、大型商业银行的业架构转型实践目 录1.业务与 IT 之间的桥梁32.银行业务架构的演变43.银行业务架构设计和实践64.业务架构设计的难点95.业务架构设计中的 trade-off11随着云计算、大数据、区块链和 AI 以及移动互联等新一代信息技术的发展，企业数字化转型加速。市场在变，需求也在变，面对高度创新和充满不确定性的敏态业务，为快速交付高质量的软件产品或服务，企业需要有更好的业务架构设计，去适应不同阶段的业务特性。何为业务架构设计？企业的业务架构设计需要考虑哪些因素？业务架构设计的难点和挑战是什么？企业应该如何权衡？.面对这些问题，InfoQ 记者采访了 QCon 全球软件开发大会 2
2、020（北京站）的讲师、企业级业务架构设计：方法论与实践一书作者建信金融科技有限责任公司付晓岩老师，请他从企业级业务架构设计实践者的视角聊聊这些问题。2000 年大学毕业后，付晓岩就加入建设银行。从业 20 年，12 年在业务领域，8 年在 IT 领域，他的脚步遍及支行、分行、总行、子公司等建行内部各层级机构。进入 IT 领域后，付晓岩近乎全程经历了建设银行规模宏大的企业级转型项目，并在项目中得到历练，从而成长为一名资深的企业级业务架构师。1. 业务与 IT 之间的桥梁IT 设计的真正目标是实现企业的价值。业务和技术应该是统一的、一体的，它们都是企业的有机组成部分。在付晓岩看来，业务架构是业务
3、与 IT 之间的桥梁。不管规模大小，企业都是一个整体，其生存、发展都依赖于企业形成内外部合力的能力，而这一能力的形成有赖于构建适宜其战略执行的企业架构（EA，Enterprise Architecture）。他认为，一个好的架构有利于企业战略的执行，尤其是数字化转型。数字化转型是业务与技术的深度融合，而融合需要机制，需要二者建立有效连接，业务架构正是这种连接方式。“战略通过业务架构分解到业务流程，并将业务能力体系化、结构化地分解到企业的各个业务部分，再转化为 IT 需求，通过与业务目标匹配的 IT 架构完成技术实现，将企业的战略和能力、业务和技术有机串联起来，构成一个协同整体。这就是业务架构乃
4、至企业架构的使命。“付晓岩表示。2. 银行业务架构的演变 从自己的经历出发，付晓岩阐述了银行业务架构的演进。相比其他行业，银行是信息化起步较早的。并且，大型银行组织结构复杂、技术开发投入高、应用范围大，因此，大型银行在架构发展历程上很有代表性。以国内银行为例，其在架构方面的发展历程如下：80 年代：分散架构 20 世纪 80 年代后半期，银行开始引入主机系统，这时构建的业务系统“高度”分散。每个地级市都有自己的业务系统，不同城市间的业务无法联通。以一笔汇款业务为例，现在是实时转账、零级清算、秒级到账，而过去是多级清算。跨地区汇款，从一个城市的网点到自己的市分行，市分行到省分行，省分行到总行，总
5、行到目标地的省分行，省分行到市分行，市分行到网点。可想而知，这种方式效率极低。90 年代：大集中架构 90 年代末，随着计算机性能的提升和网络的发展，银行对数据集中的需求越来越强烈，因为先有数据集中才能实现业务集中。因此，银行的大集中架构拉开帷幕。付晓岩表示，“大集中可以构建全行统一的业务系统，这对业务效率的提升是不言而喻的，但与此同时带来的问题逐渐显露，即竖井式开发、烟囱林立的问题。”2011 年左右：企业级架构 据付晓岩介绍，建行在 2011 年开始进行企业级转型，设计全行统一的企业级架构，包括企业级业务架构和 7 层 12P 的企业级系统架构。2017 年，整个工程结束，建行内部一体化初
6、步完成。数字化时代：开放式架构 不过，架构的演进不会就此“打住”，内部统一后，银行更重要的是适应面向数字化时代的开放与融合要求，深度参与到生态建设中。这一阶段是开放式架构，真正从社会分工、生态分工的角度，结合生态伙伴、客户情况，综合分析架构解决方案。其设想如下图所示：付晓岩指出：数字社会必定是一个与今日大不相同的“新时代”，无论是企业，还是个人，所有参与者都将迎来一个转型过程。对企业而言，架构”新时代“的到来是注定的，这个”新时代“一定是业务架构与技术架构、业务与技术深度融合的时代。3. 银行业务架构设计和实践 考虑因素 第一，目标的匹配性 企业需要清晰了解目标是什么？要解决的问题是什么？架构
7、设计不是为了概念而设计，企业不是为了做业务架构而做业务架构，也不是为了上“中台”而上“中台”，都是为了解决问题。付晓岩表示，“目的与手段要相匹配，目标的大小决定了业务架构设计的力度。”第二，资源的适配性 企业级业务架构设计不仅需要投入业务和技术人员，而且还需要有经验的业务架构师进行指导以逐步培养公司自身的业务架构师。“由于业务架构领域还比较小众，有经验的企业级业务架构师很少，更多的是技术架构师。像一些失败的中台项目一样，没有与目标匹配的资源也是项目成败的关键。”他表示。当然，即使有了业务架构师，如果没有足够数量的企业业务和技术人员配合，业务架构师也不能编出“架构”来。第三，时间的适配性 企业级
8、业务架构设计不能也不该很快，这是对企业自身的深入解读和对未来的严肃规划。它需要一定的时间投入，如果抱着“吃快餐”的心态，那项目质量很难保证。虽然架构设计不是一次搞定，需要演化，但是要为“打地基”投入合理时间。第四，耐力的匹配性 这里的”耐力“指的是坚持以企业级业务架构为核心，长期驱动企业业务管理、IT 管理的耐力。付晓岩认为，企业级业务架构是一种“秩序”，而“秩序”的维护需要耐力，如果没有坚持的定力，那一次性的成功，很可能换不回企业的投入。企业需要的是维持持久的竞争力，也自然需要耐力上的付出。业务架构设计的三个阶段 以银行为例，其在进行业务架构设计中一般有几个阶段。首先，建立明确的企业级业务架
9、构设计工程项目，并任命强有力的行级领导进行统一管控，将相关业务部门、技术部门全部拉入工程项目，以确保决策能力和执行能力。无论国内还是国外，企业级项目都是“管理者工程”。其次，进入项目过程，这时要明确战略目标，即银行针对多少年的战略目标进行架构设计，确定战略目标是什么，战略目标对应的战略能力有多少，目标越大，需要分解的能力自然越多。然后，形成现状模型。将银行现有的业务流程模型化、结构化，通过统一的企业价值链进行分类、整合、标准化，并将战略能力分解到现状模型中，将模型与战略对齐，识别需要改变的业务流程，这就产生目标模型。付晓岩指出，尽可能在架构设计过程中，将全行统一的数据模型一并设计出来，然后结合
10、数据模型和流程模型，提升标准化程度，设计出业务组件。最终形成包括战略、战略能力、流程模型、数据模型、组件模型的企业级业务架构。业务架构设计虽然不求快，但也要注意合理控制时间，“一到两年是比较合适的首次建模周期”。建行业务架构设计实践：六年磨一剑 2011 年到 2017 年，建行进行的“新一代核心业务系统”建设项目，正是通过企业级业务架构设计驱动的，也被称为“六年磨一剑”。整个实践，先从战略定位开始，分析建行的十二五、十三五规划，确定全行的整体战略目标。并且，还将战略目标分解为更细的战略能力举措和更细粒度的战略能力需求，“其目的是为了让战略落地具有更清晰、操作性更强的要求”。其次，进入现状建模
11、和目标建模阶段。这是将建行实际的业务和改进举措与战略对齐的过程。经过这样的模型设计过程，包括价值链、流程模型、数据模型、产品模型、用户体验模型和业务组件在内的整体业务架构设计和架构资产即形成。据悉，总体架构设计大约花费 2 年时间，这与建行庞大的体量和业务复杂度有直接关系。同步完成的还有适配整体业务要求的技术架构，即 7 层 12P 的方案。然后，开始根据企业级业务架构和技术架构进行具体项目落地。整个企业级转型总体分为三期，每期也有不同的小周期，由转型项目的 PMO 统一管控进度。期间，还进行了海外建模，即实现全球架构一体化的海外模型设计及海外实施。2017 年，建行公开宣布工程结束。据公开信
12、息介绍，实际落地 114 个业务组件、整合设计 900 余个业务活动、标准化 4500 余个任务、3000 余个数据实体、150 余个基础产品和 1 万余个可售产品，“在世界银行领域，这是首次完成如此大范围和深度的企业级业务架构设计与实施”。4. 业务架构设计的难点技术难点：标准化 从技术层面讲，业务架构设计最大的难点是标准化。标准化是判断服务异同和颗粒度的重要依据，这是各类架构设计中的难题。建模离不开标准化过程，做企业级模型要横向对比企业所有业务领域，以期望在设计上实现“以更少支持更多”，并实现快速的灵活响应和减少重复开发这两个目标。业务架构模型的标准化包括数据标准化、任务标准化两部分，这两
13、者相辅相成，通过数据间的比较可以更好地进行任务标准化，而通过与任务的结合也能更好地判断数据定义是否准确、数据标准化是否到位。除了技术挑战，还有诸多工程难点。工程难点 1：捷径难寻 了解 DDD（领域驱动设计）的人可能知道，DDD 对企业级不抱太大希望，认为企业级的建设路径只能是一个领域一个领域的不断尝试融合，无法通过自上向下的规划产生。在付晓岩看来，金融领域恰恰是一个很不“专业”的专业，里面的东西五花八门，看似都在一个领域，实则“千差万别”，各类业务的共性在于客户（同一群客户），围绕客户共建一个账户体系。换句话说，如果自上向下看，客户和账务应该是企业级的，而其他部分，需要一个领域一个领域的研究
14、，这也是建模和标准化的难点。因此，企业架构建设的难度跟企业所在行业的特点有直接关系。没有一个通用的企业级业务模型可以随便套，“阿里的业务架构套不到银行头上，银行的业务架构也套不到阿里头上”，甚至一个行业内，企业跟企业间内部特点的差别，也会决定企业架构建设路径和结果的不同。没有简单复制的模式能帮你快速切换到企业级，“自己的路只能自己走”。但是，需要所有从业人员共同探索的，也恰恰是如何构建成熟的行业级模型，这是未来实现大规模软件生产的关键。工程难点 2：文化难建 多数情况下，企业级不是一个单纯的技术问题，这让技术人员非常为难，因为这根本不在其能力范围内。如果是一个业务种类繁多、部门庞杂、等级森严的
15、传统企业，建企业级相当于对部门边界、协同关系的重新界定，它对企业文化的依赖和改变都很强。工程难点 3：权责难定 在组织中，一件事情能做好，前提是做事的人权责匹配。但是，架构定位的困难在于，权力太小，不足以维护企业级；权力过大，又会发展成新的部门化组织，可能会导致架构决策行为方式出现“僵化”。建立合适的集体决策机制很重要。工程难点 4：长志难立 企业级（项目）的长期坚持是件难事，它的放弃和崩坏不一定是是架构组织撤销、机制停掉这么激烈的动作，而是各种“畏难情绪”、“客观原因”导致的缓慢的无序，它是一个个需求的分配、落地的偏离堆积产生的。并且，“破窗效应”对它的影响也很明显。总之，一定不要搞“一次性”的企业级工程。5. 业务架构设计中的 trade-off 在业务架构设计中，企业除了“直面”挑战，还要权衡诸多事宜。付晓岩认为，业务架构设计是个迭代的过程，要允许反复和调整，不能武断，没有耐心。首先，不能允许简单的“拍”结构。架构师必须具有开放性，保持谦虚。架构师是“中心”，但不要总把“权威”看得太重，架构是企业整体资产。从某种角度说，企业做架构正是为摆脱对特定架构师的“单点依赖”，让架构工作能保持“业务连续性”。因此，架构设计要保持这种谦逊，这样才能让更好的设计思路进入设计师的视野，进入设计方案。其次，允许什么样的架构调整。1.查漏补缺。项目有周期，每个环节都有一
