您当前的位置:首页 > IT > 新闻内容

从银行数字化转型谈IT架构支撑

时间:2019-03-14 19:09:51  来源:  作者:  浏览量:

 从银行数字化转型谈IT架构支撑 

 

快速实现以用户为中心的客户旅程设计,意味着未来的内外部应用/服务之间的相互协作会越来越密切,包括后端业务系统、渠道系统以及外部生态之间。

这要求银行能够快速进行内部服务的集成和整合,能快速对接外部场景,这样才能做到以用户体验为核心,为用户提供方便、快捷的服务。

而数据驱动的迫切需求也将使银行越来越重视数据质量和数据价值,使数据“业务化”,通过数据让银行了解客户,为客户提供定制化服务。

这对银行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系统对接以及常见的银企直连等等。

已有位网友发表评论
网友评论

登录名: 匿名发表