银行IT应用架构变迁

     分类 [产品经理]
2023/12/15 9:43:37 浏览量  1904 喜欢  60
导读:在科技金融、数字金融的大背景、新趋势下,我们若想更合理、更有效的完成银行业务数智化转型和创新,一个基础能力便是要了解整体的IT应用架构情况。

银行IT应用架构变迁

 

 

这样才能知道自己的业务处于哪个层面,哪个位置,有什么关联业务、关联系统,当下的设计方案会对现有架构产生什么影响,是否符合全行数智化战略等等。

 

另外,为什么我们在架构评审时总是不通过,好像架构师在刻意为难一样。其实并不是架构师有意为之,而是信息差和视野差的原因,因为我们总是以单一视角(微观)来看待这件事,忽视了从中观角度对业务架构、应用架构的认识。

 

所以,本文将以我近些年在不同银行的架构实践,概括性介绍银行IT架构的演变过程。因为篇幅有限,笔者也非架构专家,文中若有不足之处,烦请同行专家批评指正。

 

关于银行从传统线下记账,到后面的系统化(线上化),再随着移动时代的发展,逐渐变成数字化的进程,很多书中都有比较全面的描述,比如《王剑讲银行业》、《大众金融》,微信读书上都有,在此不再赘述。下面我来从“实用性”的视角开始介绍。

 

一、最简单的架构关系

 

银行系统中,什么最重要?——钱最重要。

 

但钱是一个物品(抛开数字货币),反映到系统中,其实就是一个个客户下的一条条数据。这些数据是系统的重中之重,是业务开展的核心,所以承载记录“钱”的系统,被我们称为核心系统。

 

这里的“核心”二字,是个名词,它就叫核心系统。和我们理解的形容词“核心”不一样,这个概念我刚入行的时候理解了很久,才慢慢从形容词核心过渡到名词“核心系统”。

 

我们举一个最简单的例子,也是上世纪数字化刚刚起步时,很多小银行的实际情况。

 

张三来到银行网点,在柜台存了一万块钱,这个过程从应用层面分析,最少涉及到两个系统:柜面系统、核心系统。

 

交易从柜面系统录入要素,之后上送到核心系统进行验证、处理、反馈,这就是一个最简单的交易关系。

 

类似的,还有李四去ATM机存取钱,同样是从ATM系统录入要素,并进行基本信息验证,之后上送到核心系统进行处理、反馈。

 

银行IT应用架构变迁

 

然而,刚才只是存取钱,银行还有很多其他业务。比如我们以光大云缴费平台中的代收业务为例,在线上缴费推出之前,类似的代收业务需要去柜台办理。当时银行就是在发挥自己线下网点覆盖度广的优势,让用户能够就近缴费。

 

但是代收业务中,还需要对接各个第三方机构(如水厂、燃气公司、物业公司等系统),即真正的收费方。因此,业务架构变成了三层。

 

银行IT应用架构变迁

 

随着业务的发展,核心系统需要处理的业务越来越多,不仅有代收、代付,还有很多支付结算、理财、保险、司法查控等业务,都会在核心系统加一层、再加一层。

 

每种业务都有自己的特色机制,久而久之,核心系统变得越来越“臃肿”,这也是第一个阶段显著的特点:“重”(zhong)核心。

 

核心系统里面的数据非常重要,随着里面包含的业务变多,维护成本越来越高,运行的安全性、稳定性、效率都面临着严峻的考验。

 

二、天下大势,合久必分

 

为了缓解核心系统的压力,从“业务解耦”的角度来看,便需要将核心系统中的业务应用部分逐渐剥离出来,让核心专注于处理账务和账户相关的任务,因此,在业务架构层面将进入“瘦核心”阶段。

 

于是,像代收、代付类的业务系统被拆出来了,像存款、理财、贵金属、基金代销等业务也被拆出来了。

 

每个业务的第三方都由业务系统自行对接,一个业务发起后,大致逻辑是:渠道->业务系统->第三方->核心系统->各种结果返回。当然,里面的顺序不同业务会有差异,在此大家能够理解主体意思即可。

 

这时,业务架构图大致变成了这种效果。里面会有很多很多业务系统,也会有很多外部合作机构。

 

银行IT应用架构变迁

 

同时,随着互联网渠道的兴起,像手机银行、网上银行、移动展业等互联网渠道应运而生。而银行的系统都是部署在绝对安全的“内网”,与互联网之间的传输交互,与传统的渠道直接通过内网连接的方式也有很多不同。

 

而且当银行的业务开始丰富、延展时,还会有很多第三方渠道、合作方,通过互联网模式将业务要素传入行内,因此,为了完成内外网的安全互通,银行增加了“接入网关”这个模块。

 

在资金交易方面,不仅有本行的资金处理,还有很多跨行交易的诉求。而核心系统主要进行本行交易处理,关于跨行交易,也有不同的系统承载。

 

于是,上面这张图又可以调整成这样。

 

银行IT应用架构变迁

 

紧接着,“瘦核心”阶段下的问题也逐渐体现出来,那就是业务系统太多了,像代收代付类的业务,一家银行有几十上百个都很常见。

 

每个系统都需要维护,而且很多系统之间存在不少共性,因此在系统建设层面存在很多冗余和资源浪费。

 

三、天下大势,分久必合

 

因此,“瘦核心”之后,银行的架构演变来到了第三个阶段:平台化。

 

将同类业务组合提炼,对外形成一个统一的产品,对内进行合并,并通过技术升级、标准流程制定等理念,提升开发、维护的效率。

 

所以,我觉得像光大云缴费这样的平台级产品,也属于这个阶段的产物。

 

  • 同类型的还有“统一支付平台”,将本行、跨行的支付交易做了提炼、整合;
  • “综合财富平台”,将理财、基金、保险、存款等理财类产品做了抽象、归纳;
  • “中间业务平台”,将代收类、代付类多种交易做了汇总、统一;
  • “营销平台”,将各类客户、各种渠道下的营销场景进行归类、配置;
  • “外联网关”,将行内与行外系统交互的规范进行管理、统筹。

 

各个业务系统都会产生很多业务数据,对于数据的处理,又拆分成了数据仓库、报表平台、客户统一视图(ECIF)等不同维度的数据类产品。

 

通过整合,将某类目标聚焦,既在架构上更清晰,又能通过技术和业务上的拓展性支撑未来多年的业务发展。

 

当然,上述介绍中提及的系统,仅是银行IT业务系统中的一小部分,还有很多监管类、管理类、风控类、场景金融类、银企合作类、资金类、资管类、同业类等等业务应用。

 

但从整个架构演变过程来看,具体业务差异不大,更多是基于科技发展、系统稳定、业务趋势等多个方面形成的“合理化迭代”。

 

本文也没有提到ESB(企业服务总线)的价值和接入模式,不过ESB作为非业务系统,在产品设计层面也不会有什么影响。

 

文章至此,介绍了银行IT架构变迁过程中的三个阶段:重核心、瘦核心、平台化,最终形成类似于下图这种架构模式。

 

银行IT应用架构变迁

不同的银行具体的架构,以及系统的名称都会有差异,但本质的结构和关联情况大同小异。

 

四、数字化与数智化时代的业务挑战

 

介绍完应用架构的变迁,最后聊一聊我对于理解整体架构这件事的意义。

 

我们若想在当下的架构里增加一个新系统,要考虑的要素还是蛮多的,因为任何系统都不是一个独立的个体,所以要考虑这个系统在业务场景中,和其他系统的联动性,还要考虑功能的复用性,以及功能的“载体”(即放到哪里)。

 

当下银行在新建系统中的考量和审核都比较严格,一是为了避免重复性建设,能够复用、能够整合的,依然本着复用和整合的目标。

 

二是很多系统上线之后,实际应用效果并不好,因此需要更加明确,更加具备可行性和业务价值。

 

三是近年来银行的经营效益也在经受很大的挑战,新系统建设的花费是一笔不小的数目,因此也不会像前些年那样顺利。

 

基于上述原因,很多情况下业务部门提出的新需求,可能就需要在现有应用中开发,或者将一个业务拆分成不同的模块,放到不同的应用中。

 

因此将对产品设计者提出新的考验,不仅要进行产品方案设计,还要跨部门沟通,多部门协作,做系统权衡。

 

另外,即便是同意了新建系统,这个新系统在设计过程中也要势必要遵循本行的开发规范、架构规范。

 

比如用户登录是否要对接行内的统一认证模块?密码加密是否要对接行里的安全密钥模块?线上的合同或者回执,是否要对接行内的电子签章模块?营销短信或通知短信,是否要对接行内的短信平台?

 

比如,和其他系统对接是系统直连,还是通过ESB,或者其他与ESB类似作用的服务总线?(因为很多银行不只有一个ESB,还有很多前置系统、网关系统,同样承载了系统间统一对接的作用)

 

再比如,系统是自建渠道,还是挂载到现有渠道?如果是挂载现有渠道,又要遵循渠道侧的设计规范、接入规范、安全规范。系统是否涉及资金交易,若涉及,资金交易通过哪个支付系统处理?系统产生的数据如何入仓?

 

还比如,我们需要某些数据,这些数据是从哪里获取?数仓?核心系统?卡系统?还是哪里?不知道,你得挨个问。

 

以上种种,还有未罗列的很多问题,都是在实际数字化推进过程中将要遇到的问题。

 

因此,银行业务的数字化,并不单纯是产品设计的问题,更多的精力是如何在当下的环境中,形成一个多方认可的执行方案。

 

我觉得,这些问题是未来影响银行快速实现数字化、数智化的最大“拦路虎”,更可怕的事,这些问题没有标准答案,没有可遵循的流程或制度,只能靠我们一次次的沟通、讨论、权衡,甚至妥协。

 

写在最后

 

我从2015年8月参加工作开始,便莫名其妙的踏入了银行数字化转型的浪潮之中,八年间在全国几十家银行做过项目、售前,从测试的执行,到项目的把控,到需求的分析,再到产品的设计、方案的制定,越来越觉得大多数从业者缺少对整体应用架构的认识和理解,因此在执行中经常遇到“不可控”的阻碍。

 

随着工作的深入,我反而觉得所谓的“不可控”,其实是认知差和信息差的结果,当我们试着站在全局的角度,或者对方的角度考虑这些问题时,似乎也能理解了。

 

其实银行非常需要专业的产品经理来推动数字化战略转型。

 

而传统的银行从业者缺少互联网思维和产品思维,市场上的产品经理又缺少对银行业的理解,很多乙方的需求分析师也是半路转行,或者仅限于执行而缺少顶层设计能力。

 

因此,当下的银行,尤其是城商行、农信社、农商行,亟需补充专业的数字化人才。

 

最近一年,我翻阅了很多银行相关的书籍、文章,没有找到一篇真正适合银行IT从业人员、业务人员、产品设计者、新入行人员了解银行IT应用架构的介绍,因此将自己的理解汇总成这篇文章。

 

希望能够帮助更多的银行从业者,了解应用架构,进而更有效的推进金融领域数字化创新,写好未来“普惠金融”、“绿色金融”、“养老金融”、“科技金融”、“数字金融”五大篇章。

 
本文均为个人观点,与供职机构、合作伙伴无关。

 

标签

微信扫一扫,分享到朋友圈

微信公众号

相关推荐