商业银行企业级架构变革，一场关乎生死存亡的“大手术”！

企业架构是以实现企业战略为导向的结构化方法，通过企业级的业务能力规划，桥接业务目标与技术实现。其核心价值在于支持业务与技术的深度融合，从而为企业内部创造一种通用的“共同语言”。

企业架构概念最早可追溯至1987年提出的Zachman框架，其从战略和业务目标的角度出发，为企业的IT系统设计提供了系统化的架构方法。

在实践中，EA的关键在于抽象出可重用、模块化的“架构资产”，包括业务规则、流程逻辑以及数据结构。这些架构资产在企业内部通过标准化形成共识，支持各业务功能灵活组合并加速技术实现。

国内多年研究与实践软件、产品、IT架构者众，主因在于国内企业多招聘软件/IT架构师，这映射出了彼时企业家对业务与科技的认识程度。相比之下，银行管理层在此方面认知相对领先，其业务特性迫使它们必须重视业科融合。

于前车之鉴，我们先看看大洋彼岸的美国在银行架构领域的基本发展脉络，再看自己的路：

2010年：美国颁布《多德-弗兰克法案》

这一法律针对银行的系统性风险和信息透明性提出全面监管要求，推动银行业采用更先进的架构体系来提升风险管理和信息共享能力。法案强调金融机构的技术基础设施和数据管理。

2013年：美国颁布金融稳定监督委员会（FSOC）金融机构风险评估指导

其重视企业架构在数据管理和风险控制中的作用。这一指导主要关注如何利用架构来支持数据集中管理，从而在面临危机时能快速应对，提升架构在风控中的重要性。

2018年：美国颁布《金融科技发展促进法案》

通过该法案，银行被鼓励采用模块化和可扩展的架构，以更快响应市场需求，并推动低代码和无代码的使用，提升技术的敏捷性和业务适配性。

2022年：联邦储备的企业架构监管建议

联储提出建议以确保银行的企业架构能灵活应对不断变化的金融风险：包括企业架构要支持多种数据治理策略，帮助银行在应对外部威胁和快速增长的数字金融服务时具有足够的灵活性。

2023年3月：银行业风控措施升级

在硅谷银行等几家区域银行出现流动性危机后，美国监管机构如联邦存款保险公司（FDIC）和美联储采取了多项应对措施，进一步推动企业架构优化以应对潜在的金融动荡风险。

以美国4家标杆银行为例：

1. 摩根大通

其致力于利用企业架构优化技术和业务的结合。采用模块化架构设计，以支持应用的快速开发和灵活部署；通过企业架构平台整合大量数据资源，支持风险管理、客户服务和决策制定。其数据管理能力大幅提高，增强了数据治理和分析功能，为其提供更强的风险预判能力；通过云架构迁移，增加系统的弹性和安全性。

2. 美国银行

其以“端到端”业务流程的优化见长，实施了集中化的数据治理和云优先的架构战略。集中化了数据管理架构，形成企业级的数据平台，支持跨部门数据共享和分析；通过将关键业务迁移至云平台，减少依赖本地基础设施的成本，增强数据安全性并缩短了应用开发和部署的时间；采用模块化的设计框架和广泛的API使用，提升了业务协作效率并支持外部创新合作，尤其是在金融科技方面的合作项目。

3.富国银行

其企业架构建设主要体现在其风险控制和IT系统集成能力上，尤其在近年针对反欺诈和合规性的监管需求中，富国银行的EA战略有重要的推进。其使用企业架构集中管理风险和合规流程，涵盖反洗钱（AML）、反欺诈以及客户尽职调查（CDD）等功能，确保合规要求在其架构中贯穿；通过企业架构改进其数字化服务，进一步支持移动端和在线银行业务的发展。其架构为增强客户体验和扩展数字渠道提供了强有力的支持 。

4. 花旗银行

在EA应用方面侧重于跨部门和全球范围的业务整合，通过集成的企业架构支持其全球业务。其利用企业架构整合全球业务，通过标准化和模块化的架构体系来统一跨地区的业务流程；在EA策略中将安全和合规作为关键要素，通过企业架构体系化地管理数据安全和合规性，并实现自动化的风险监控和预警机制 。

近年，我国商业银行在国家各部门的倡导下，在逐步加大企业架构的探索和应用力度。

2020年9月：国资委发布《关于加快推进国有企业数字化转型工作的通知》

明确指出，国有企业应“以企业架构为核心构建现代化IT治理体系”，实现IT投资与业务变革的持续适配，以促进业务与信息化建设的深度融合。

2021年5月：国务院发布《金融业数据治理指引》

指引强调，金融业应构建有效的数据治理架构，以提升数据资源整合和决策支持能力，确保数据安全。

2021年12月：银保监会发布《银行保险机构公司治理准则》

文件提出金融机构应将信息技术作为企业核心支柱之一，要求在公司治理框架中加入技术治理和企业架构设计的要素，强调在业务规划与技术支持方面建立有效的架构协同机制。

2022年1月：银保监会发布《关于银行业保险业数字化转型的指导意见》

文件进一步推动银行业数字化转型，强调要“加快企业级业务平台建设，强化企业架构设计”，并提出通过标准化和模块化推动共性业务功能的建设，以支持银行在信息化基础上的创新与扩展

2022年10月：银保监会《金融科技发展规划（2022-2025年）》

该规划鼓励银行构建智能化、模块化的业务架构，提出通过低代码开发等工具增强架构的灵活性和业务适配性。这一文件进一步阐明了企业架构在业务创新和数字化服务中的关键角色。

2023年：《中国银行业数字化转型研究报告》由多家机构联合发布

报告指出，银行应通过企业架构优化来驱动数据管理、提升风控能力、优化客户服务，形成面向未来的企业架构体系。

据中电金信统计，目前国内已有6家大型国有银行、5家全国性股份制银行、2家领先城市商业银行、1家农村金融机构及2家非银金融机构逐步实践并推进企业级架构建设，越来越多的中小银行和非银机构也开始探索。

对于商业银行而言，EA的建设不仅仅是一个技术工程，还需要与银行的组织机制和业务流程深度适配。EA的构建程度将直接影响银行的运营效率和市场竞争力。

国内银行业已探索企业架构应用十余年。建设银行是国内最早实施EA的银行之一。2017年，建设银行完成了“新一代”核心系统建设，形成了“四个一”企业级实施方法：一套模型、一套IT架构、一套实施工艺和一套管理流程。

此方法涵盖集团层面的流程模型、数据模型、产品模型及用户体验模型。

工商银行则通过“三横三纵”的业务架构体系，即产品建模、流程建模、数据建模与业务领域、业务组件、业务对象的架构设计，形成了独具特色的EA品牌。

目前，商业银行的EA建设路径主要有三类模式：

一是以建设银行为代表的“全面企业架构”模式，对所有业务领域和系统进行企业级架构改造；

二是以邮储银行为代表的“一横一竖”模式，基于全行顶层架构开展个别业务领域的深度建模；

三是以四川农信为代表的“领域试点”模式，针对某一业务领域进行企业架构设计。

从总体上看，EA的构建应着眼于打破部门壁垒、提升研发效率、优化资源配置和积累企业资产上来，以切实推动商业银行转型。

汤姆格雷夫说：“企业架构的目标不是设计一个完美的模型，而是提供一个有意义的框架，使企业能够实现持续的变革与创新。”

From The BIAN® reference model eg. for the financial industry

商业银行的竞争已从产品层面的单一竞争转向生态层级的企业级竞争。传统的“竖井式”业务与技术架构逐渐暴露出其局限性，例如内部壁垒、重复建设以及条线利益冲突等。

企业架构则谋求通过构建统一的业务模型、系统平台和管理工具，将各业务条线的能力整合到企业级架构中，实现全行的能力共享。

企业战略可以通过架构设计和模型构建，全面渗透至产品和业务的各个层面。

在“打破部门化”的推进过程中，主要挑战在于企业架构项目的执行与企业级组织结构建设未能同步展开。

要落地企业级能力，必须同步配套建立企业级组织结构。企业架构项目虽然在流程和工艺上能初步冲击“烟囱式”结构，但组织架构、职责边界和岗位制约的重构才是真正推动企业级能力落地的关键。

在某些银行中，企业架构项目与组织建设未同步推进，人员和业务管理依然沿用条线模式，导致EA实施存在妥协或偏差，具体表现为业务模型缺乏跨领域复用、基础产品仅限于单一条线使用，以及后续业务部门偏好新建独立模型，而非复用现有模型。

因此，企业级的标准化和模块化改造容易受限于条线分割的环境，企业级能力的推动受限于“缺乏统一的企业级利益代表”。

企业级能力管理的职责应在EA项目实施初期便同步梳理。

首先，若建模等基础工作在初期偏离企业级方向，后期的纠正将极具挑战。

其次，项目启动时进行管理职责分配相对容易，而在项目完成后进行职责调整则更为困难。

商业银行需设立统一的企业级能力管理部门，并赋予该部门实际职能，而非仅承担框架化的责任。

例如，在模型管理方面，模型职责可分为模型规范管理、模型内容管理和模型工具管理，企业级能力管理部门至少需承担前两项，以确保跨条线的企业级建模顺利推进。

当前，实施“全面企业架构”或“一横一竖”模式的大型银行多已同步推进企业级组织体系建设。

伊万马克说：“当我们构建企业架构时，我们不仅是在设计一个系统，而是在设计一种未来的工作方式。”

随着市场需求变化和客户需求增长，银行信贷产品的多样化和迭代加速对银行内部资源组织和研发效率提出了更高要求。

通过EA的组件化、模块化和参数化改造，商业银行能够加快产品和业务的组合配置，显著缩短市场响应周期。

提高研发效率的主要挑战在于业务模型的开发和测试未得到全面应用。根据全国金融标准化技术委员会的业务建模指南，在EA模式下，业务需求应首先转化为业务模型，以指导IT开发和测试。

然而在实际操作中，开发和测试往往仍依赖业务需求而非业务模型，特别是在流程模型的应用中尤为明显。

这一现象反映了企业级能力和条线级管理的磨合问题。从开发部门的角度看，业务模型的逻辑完全来自业务需求，但建模可能增加开发工作量和复杂性，使得开发部门倾向于直接基于业务需求进行开发。

由于业务模型未全面应用，EA在效率提升和配置灵活性方面的效果难以充分发挥。

为应对上述问题，应强化业务模型在IT实施过程中的应用。

首先，业务模型需与业务需求区分定位。若要推动开发部门使用业务模型，应提供超出需求范围但具有实际价值的内容，例如流程模型与产品/数据模型的映射、跨产品公共模块的整合等开发部门关注的领域。

其次，从制度上对IT实施工艺进行自上而下的规范。例如，有些银行通过关键岗位——业务分析设计师，使其相对独立于业务系统开发团队，基于业务模型进行设计。

最后，测试部门需基于业务模型进行测试，确保开发内容符合业务建模要求，并在银行内部建立后评估机制，以防止IT实施偏离业务建模目标。

伊万马克说：“技术资源的下沉需要一个平衡的架构，它不仅要支持基层的自主性，还要确保全局的一致性和控制。”

目前，部分商业银行的开发与测试资源集中在总行。

地方分行的特色业务需求需先提交至总行，由总行分析、起草需求并排队实施。这种链条流程冗长，沟通成本高，并且责权利分配不匹配。企业架构则通过标准化业务模型的建立，能够有效将产品配置权限下放至分行。这样，分行可自主设计、装配并上线分行级产品，从而提高市场响应速度。

在实施过程中，基层人员难以掌握企业架构的相关方法论。下沉技术资源涉及责权利的协调，在赋予分行研发权的同时，也对其管理和执行能力提出更高要求。

EA涵盖众多概念与逻辑体系，在实施后，原来的业务操作流程可能会转变为更为精细的结构化流程，可能加大员工对新系统、工具及流程规范的学习难度。

原本仅需简单赋值的业务参数，现在需要员工去维护具备复杂属性和相互关联的结构化条件。因此，基层员工必须不断提升自身的技术能力、流程管理能力和产品管理知识，以确保能够有效地运用EA。

尽管在初期阶段，员工可能会面临更大的工作压力和负担，但随着时间的推移以及技能的逐步积累，工作将趋向标准化和自动化，并开始释放赋能员工的力量。这就好像用小米加步枪的士兵要开始学习用与远程连接的手持智能导弹一样。

这一能力的提升将促使技术资源得以更广泛地应用于业务一线，进而推动业务流程的持续优化和高效运作。为此，组织及其员工需要给予充分的适应时间和耐心、培训、培养，以顺利度过这一转型期。

建议措施

为更好地支持分行掌握企业架构方法，可从外部支撑与内部激励两个层面推进：

1 外部支撑

在企业级架构系统中，为分行提供差异化操作界面，并配套详尽的条件说明与案例。对于偏重方法论或技术实现的内容，总行可预设模板，分行根据实际情况调用，减少复杂的输入需求。

对于不熟悉技术流程的分行，总行配置完成的业务模型应能直接生效，无需分行重复开发和测试。建议银行转变需求设计与开发工艺，从关注基础产品维度入手，以保障配置成果的快速上线。

2 内部激励

当前市场中，系统定制化服务成为政府和优质企业的合作条件，分行对技术资源掌握的意愿较高。总行可通过绩效考核与资源配置手段，将分行的职责和权限有机结合，促进分行对技术资源的有效使用。

分行需具备相应的企业架构知识和技能，才能使用EA相关模型与工具，并享受数字化转型的相关红利。通过学习专业知识，和实际操练演习，总行可确保分行在具备必要知识后，方能更好地实施企业级架构，从而实现整体效益提升。

马丁富勒说过： “软件架构是一种意图，而企业架构是一种共识。”

这句太经典。

在需求管理方面，部分商业银行采用逐次优化的方式处理独立需求，未对同一产品的历史需求文档进行整合或积累。如此，经过多次优化后的产品，内部可能缺少清晰完整的业务全貌描述，甚至无法在组织中准确传达产品的整体逻辑与功能。

通过企业架构中的业务建模，则能够实时呈现产品迭代的全量更新内容，并同步优化，以便相关岗位实时掌握产品的全景视图与详细信息。

挑战：业务模型范围边界的缺乏标准化

整合业务全貌的核心挑战在于业务模型范围的标准化问题。企业架构作为一套抽象方法论，在银行业的具体实施中缺乏清晰统一的模型边界。各商业银行在实践中对业务建模的内容范围有所不同。

例如，对于同一类车险产品，一家银行可能仅基于五个主要条件来设定保费，而另一家银行可能会依据几十个不同的细分条件，如车辆品牌、维修历史、驾驶员的行为模式、地区风险等。

此外，保险产品的定价逻辑可能不仅仅局限于内部的自动计算模型，还涉及外部的风险管理规则、市场定价策略等因素。

因此，不同银行在构建产品模型时，内部逻辑和外部逻辑的划分比例，以及这些条件的细化程度，会有显著的差异。

业务模型边界的划定方式直接影响银行的管理效率和整体业务模式。

建议：结合银行业务实际，标准化模型资产的范围

建议在企业架构实践中，结合银行业务特点，建立模型资产的范围标准。

例如，在产品建模过程中，首先遵循方法论原则，确保建模内容符合产品条件的定义。需要识别并排除非控制性内容，确保产品条件具有明确的控制含义，即包含对可售产品的业务约束、流程走向影响等内容。

没有这些控制特征的内容应排除在产品条件之外。此外，还需排除非业务相关内容，确保产品条件具备业务含义，将技术性、数据类或UI相关的内容排除在外，以保证模型聚焦在核心业务逻辑。

对产品条件、产品参数和风险控制规则的边界范围，各银行可根据实际情况差异化管理。

例如，某些银行将客户数据管理和隐私保护策略集中在总行层面，而非由各个分行自行管理。总行负责设定统一的客户数据访问、加密和备份标准，以确保全行数据的安全性和一致性。这种集中管理模式有助于减少分行在数据管理方面的差异，确保数据治理的统一性和合规性，从而更好地支持跨地域或跨业务线的运营需求。

再比如，一些银行的企业架构专注于将风险管理职能进行层级化，将宏观风险（如市场风险、信用风险）和微观风险（如单一客户的信用风险）区分开来。总行通常负责宏观层面的风险管理和策略制定，而具体产品或分行负责日常的微观风险评估和处理。这种架构帮助银行优化资源分配，确保风险管理的精准性和效率，同时避免资源的过度分散。

由于企业级架构涉及组织架构的调整和权责重构、流程重构、技术重构，其实施难度和设计难度都不相上下。对于银行业而言，实施企业级架构方法论，达成企业级架构目标是一个复杂且漫长的过程，需要一代又一代人持续的探索、努力与优化。

我不相信“为最大数量的人带来最大利益”的学说，它赤裸裸地意味着为了实现51%的所谓利益、49%的人的利益可能会，或者更确切地说，应该受到损害。这是一种无情的教条，对人类造成了伤害！唯一真正有尊严的人类教义应是谋求所有人的福祉。——甘地