现如今，银行数字化转型已成为银行业整体的发展方向。但由于银行在过去不够“开放”，存在系统间服务集成问题，无法快速对接外部场景，因此在IT架构支撑体系方面需做出一定调整，建立开放生态，进而实现数据“业务化”。

本文主要从服务集成、API服务、数据驱动三个方面，分析银行如何改变IT架构以实现数字化转型。

近年来，移动互联网高速发展，在与互联网公司的跨界竞争中，银行逐渐意识到业务阵地开始失控，利润空间受到挤压。随着危机感越来越强烈，不少银行纷纷提出数字化转型的目标，希望通过数字化转型成为数据驱动型或软件驱动型商业银行，从而在未来竞争中占据优势。

银行数字化转型有三个最主要的特征：

1.用户体验：以用户为中心的客户旅程设计

2.开放生态：与外部场景的快速对接

3.数据驱动：通过数据洞察实现企业精细化运营，对客户提供差异化服务

快速实现以用户为中心的客户旅程设计，意味着未来的内外部应用/服务之间的相互协作会越来越密切，包括后端业务系统、渠道系统以及外部生态之间。这要求银行能够快速进行内部服务的集成和整合，能快速对接外部场景，这样才能做到以用户体验为核心，为用户提供方便、快捷的服务。而数据驱动的迫切需求也将使银行越来越重视数据质量和数据价值，使数据“业务化”，通过数据让银行了解客户，为客户提供定制化服务。

这对银行IT架构支撑体系提出了新的能力要求：敏捷的服务集成、开放的API服务、智能的数据驱动。

一、敏捷的服务集成

谈到服务集成，很多人可能会想到企业服务总线（ESB）。从单个系统来看，其内部服务之间的访问基本都是网状结构，服务与服务直接进行访问是顺畅有序的，似乎无需服务总线来支持内部服务。也许有人认为这是由于单个系统内部服务数量少，逻辑相对简单，所以网状结构没有问题。

然而，在互联网（INTERNET）上服务同样是网状结构，服务之间也是直接访问，没有人觉得在互联网上需要经过一个服务总线来避免网状结构。既然小到一个系统，大到整个互联网，服务间都是通过端到端的直接访问来实现服务集成，那为什么在企业级的IT架构规划中通过ESB实现服务集成到现在仍然被很多人认为是比较好的解决方案呢？

首先来看看ESB提出的背景。随着银行近二、三十年的发展，其IT建设从最早的一个综合业务系统开始到现在的上百个系统。随着系统数量的增加，系统间的相互访问越来越多、越来越密切，系统的建设难度和改造难度也越来越大。这就是我们经常说的牵一发而动全身，也是我们所“深恶痛绝”的网状架构的由来。

这个时候有人提出应该有个系统来解决系统间服务集成的问题，来屏蔽系统的变化对关联系统的影响，来统一管理系统间的关联关系。于是大前置及ESB就伴随着这个痛点应运而生。但为什么只有企业级架构规划中才会提出ESB的解决方案呢？其根本原因在于企业层面服务标准缺失或者滞后于IT系统建设。单个系统是由一个项目组来进行统一的设计和建设，其服务标准自然是统一的。互联网是伴随着HTTP协议问世的，其服务标准也是统一的。但银行众多IT系统的建设是各自先后完成的。

在很多年以前银行IT建设的初级阶段，银行尚没有考虑到在企业层面制定服务标准的想法。众多IT系统的服务有着各自的标准，从而导致服务间访问的难度和复杂度越来越大。由此很多银行纷纷启动并完成了ESB的建设。但其中不少完成了ESB建设的银行仍然忽视了服务标准的制定和落地，而仅仅关注在ESB的服务转接功能，认为已经从“网状架构”升级到了“总线架构”，服务集成已经不存在问题了。

实际上，如果没有服务标准或者服务标准没有落地，即使有了ESB，仅仅是把问题迁移到了ESB本身，服务集成的复杂度和难度没有真正解决。因此对于企业内部服务集成来说，ESB建设的最终目标应该是“消灭ESB”。通过ESB完成对全行各个应用系统间访问关系的梳理，根据制定的服务标准进行全面的服务治理。

通过服务治理使全行服务能够遵循统一的服务标准后，服务之间实现了便捷规范的直接访问，ESB也就失去了存在的意义。因此ESB是伴随着服务标准滞后于IT系统建设或缺乏服务标准而产生的，是“存量服务治理过程中的过渡方案”，而非银行进行服务治理的必经之路。相对于ESB，分布式微服务架构更适合银行进行服务治理，实现企业级SOA。服务集成的关键在于通过推进服务标准的全面落地，从而实现内部服务的“即插即用”。

总而言之，根据服务标准进行服务管控治理，使服务标准全面落地，实现内部服务的“即插即用”，这就是敏捷的服务集成能力。

二、开放的API服务

对接外部场景对银行来说并非新事物。为了通过对外输出金融服务能力进行获客，银行很早就在许多领域与外部场景进行了对接。例如，在商户支付场景与商场酒店MIS系统对接，在医院支付场景与医院HIS系统对接，在代收付场景与水电煤等事业单位及企业的内部系统对接，在企业现金管理场景与企业ERP系统对接以及常见的银企直连等等。

在这个过程中，大多数银行是一个场景对应一个解决方案，较少在企业级架构层面进行思考和规划，也没有以更为开放的心态提出全面对接外部场景打造开放生态的思路。每个场景的对接都是一个项目建设过程。每个项目都要进行需求沟通、架构设计、功能设计、安全设计、关联系统分析、代码编写、测试等，成本高，耗时长，更有可能项目投产后市场先机已经失去。

随着互联网金融的兴起，银行在外部场景的阵地上面对“狼性”的互联网公司的挑战，显得被动乏力。为了摆脱被动的局面，打赢这场“场景之争”，银行必须要将其专有的核心优势（金融服务能力）以更为开放的思路在市场竞争中发挥作用。

“开放”是银行未来发展的必由之路，因此一些银行开始提出 “开放银行”和“API经济”的理念，希望能够通过打造企业级的开放银行平台将银行的金融服务能力封装成API服务对外开放，将外部企业和个人开发者都视为银行的合作伙伴。通过与越来越多的合作伙伴合作，实现快速对接外部场景，全力打造开放生态圈，让银行的服务在企业的生产经营场景和个人的日常生活场景中随处可得。

想要实现以上操作，需要银行将开放生态作为银行IT架构规划的主要目标之一，通过企业级基础设施（开放银行平台）对开放互联的统一支持，从而做到与外部生态敏捷对接。

三、智能的数据驱动

近几年随着移动互联网的兴起，“大数据”和“数据驱动”成为热点。银行从互联网公司、互联网金融公司看到了数据的价值，看到了数据驱动的生产力。于是银行纷纷提出了要成为数据驱动型银行的目标。

在数据分析领域，早在一、二十年前，银行在内部管理需求的驱动下先后启动了数据仓库/数据集市的建设，并基于数据仓库对BI类应用系统的建设提供了较好的数据处理能力支撑。数据仓库及BI类应用系统的建设更倾向找共性、找趋势，为银行内部精细化管理及决策提供支持。当时一种主流的看法是银行的应用系统可以大致分为渠道系统、业务系统以及管理信息系统，其中渠道系统和业务系统是直接为业务提供支持的，基于数据仓库/数据集市的管理信息系统主要服务于内部管理，而没有直接支持业务。

实际上，数据驱动的内涵更广，它更为注重个体的刻画，更多在于对个性化决策及服务的支持。随着技术的发展，海量数据的高效处理能力已经“近在身边”。为客户提供定制化的服务已经不在是VIP客户专享的服务，IT已经能够支持银行对过去所忽视的“长尾”客户提供个性化的金融服务。

数据不再满足于为管理决策提供支持，数据驱动要求让数据进入业务流程，让数据直接为业务服务，实现闭环的智能营销、运营、风控体系。同时，数据时效性不再满足于“T+1”，实时或者准实时的数据服务以及流计算（事件触发）成了银行必须具备的能力。为了实现这一目标，一些银行先后开始了对大数据技术的研究，也开始基于大数据技术搭建数据分析平台。

为了数据能够快速“业务化”（直接为业务提供支持）和建设精准的数据洞察和实时的数据服务等能力，在IT建设方面必须要做好三方面的工作：首先是为了提高数据质量以及数据共享效率，提升数据价值，基于数据标准所打造的闭环的数据治理体系显得尤为重要；其次是为业务提供底层数据集成、数据存储、数据分析等基础能力的大数据支撑平台的建设；第三是提供基于数据洞察的智能营销和智能风控等能力的数据中台的建设。

另外，提到大数据或者数据驱动，大多数人可能首先想到的是Hadoop，把大数据和Hadoop画上等号，认为不用Hadoop都不算大数据。在大数据蔓延的今天，传统的数据仓库厂商Teradata、Oracle-Exadata、IBM-Netezza、HP-Vertica等都在做大数据，也都使各自产品的数据处理能力扩展到了PB级别。许多人把Hadoop看作是处理大数据问题唯一的救命稻草，但Hadoop仅仅是大数据平台的可选技术之一。

在大数据领域，Hadoop、HBASE、Impala、SPARK等开源技术所形成的技术体系在海量数据（包括结构化、非结构化数据）的ETL、计算、高效读取、在线分析、流处理等方面有其优势。不过大部分开源技术的成熟度与商用软件还是存在一定差距。这要求企业在使用这些开源技术时需要配备对应的基础技术专家，无形中存在巨大的维护成本。要使银行成为数据驱动型银行，重点不在于有没有用Hadoop这些技术，而更应关注在大数据技术的支持下，数据是否进入业务流程，直接为业务服务，实现数据“业务化”。

总而言之，在银行亟需进行数字化转型的今天，服务集成、开放生态以及数据驱动是银行IT架构规划的三个重点，而服务治理、数据治理是银行IT架构规划落地至关重要的两个要素。这些工作都无法一蹴而就，需要银行科技部门将其作为长期的工作重点，从架构层面由上至下稳步推进、逐步落实和完善。

银行IT架构规划的两个关键词是“核心”和“引领”：银行科技建设的核心，全行科技建设工作的引领。银行IT架构管理人员应该是科技建设工作的领军者，而不仅仅是“审核”或者“辅助”的角色。要做好银行IT架构管理工作，必须从全行业务发展的角度对IT建设进行整体考虑，将全行IT视为一个系统（One Bank One System）进行规划设计，并分解为具体的任务进行分阶段落地，并对过程进行推进和把控。银行IT架构规划不仅仅是架构管理工作的蓝图，而应该成为全行科技人员具体工作的指引。只有这样，银行的科技建设工作才能一步一个脚印在架构规划的引领下伴随业务发展向前迈进，持续积累，为银行在市场竞争中形成差异化的核心优势提供技术支撑。

作者：兴业数金研究开发中心总经理 纪建锋