为了更有效地完成银行业务的数智化转型和创新，我们不可避免地要了解银行业务的IT架构情况，只是很多时候，我们缺乏了架构层的认知，而这篇文章里，作者就梳理了银行IT应用架构的变迁及发展，我们不妨来看看。
在科技金融、数字金融的大背景、新趋势下，我们若想更合理、更有效的完成银行业务数智化转型和创新，一个基础能力便是要了解整体的IT应用架构情况。
这样才能知道自己的业务处于哪个层面，哪个位置，有什么关联业务、关联系统，当下的设计方案会对现有架构产生什么影响，是否符合全行数智化战略等等。
另外，为什么我们在架构评审时总是不通过，好像架构师在刻意为难一样。其实并不是架构师有意为之，而是信息差和视野差的原因，因为我们总是以单一视角（微观）来看待这件事，忽视了从中观角度对业务架构、应用架构的认识。
所以，本文将以我近些年在不同银行的架构实践，概括性介绍银行IT架构的演变过程。因为篇幅有限，笔者也非架构专家，文中若有不足之处，烦请同行专家批评指正。
关于银行从传统线下记账，到后面的系统化（线上化），再随着移动时代的发展，逐渐变成数字化的进程，很多书中都有比较全面的描述，比如《王剑讲银行业》、《大众金融》，微信读书上都有，在此不再赘述。下面我来从“实用性”的视角开始介绍。
银行系统中，什么最重要？——钱最重要。
但钱是一个物品（抛开数字货币），反映到系统中，其实就是一个个客户下的一条条数据。这些数据是系统的重中之重，是业务开展的核心，所以承载记录“钱”的系统，被我们称为核心系统。
这里的“核心”二字，是个名词，它就叫核心系统。和我们理解的形容词“核心”不一样，这个概念我刚入行的时候理解了很久，才慢慢从形容词核心过渡到名词“核心系统”。
我们举一个最简单的例子，也是上世纪数字化刚刚起步时，很多小银行的实际情况。
张三来到银行网点，在柜台存了一万块钱，这个过程从应用层面分析，最少涉及到两个系统：柜面系统、核心系统。
交易从柜面系统录入要素，之后上送到核心系统进行验证、处理、反馈，这就是一个最简单的交易关系。
类似的，还有李四去ATM机存取钱，同样是从ATM系统录入要素，并进行基本信息验证，之后上送到核心系统进行处理、反馈。
然而，刚才只是存取钱，银行还有很多其他业务。比如我们以光大云缴费平台中的代收业务为例，在线上缴费推出之前，类似的代收业务需要去柜台办理。当时银行就是在发挥自己线下网点覆盖度广的优势，让用户能够就近缴费。
但是代收业务中，还需要对接各个第三方机构（如水厂、燃气公司、物业公司等系统），即真正的收费方。因此，业务架构变成了三层。
随着业务的发展，核心系统需要处理的业务越来越多，不仅有代收、代付，还有很多支付结算、理财、保险、司法查控等业务，都会在核心系统加一层、再加一层。
每种业务都有自己的特色机制，久而久之，核心系统变得越来越“臃肿”，这也是第一个阶段显著的特点：“重”（zhong）核心。
核心系统里面的数据非常重要，随着里面包含的业务变多，维护成本越来越高，运行的安全性、稳定性、效率都面临着严峻的考验。
为了缓解核心系统的压力，从“业务解耦”的角度来看，便需要将核心系统中的业务应用部分逐渐剥离出来，让核心专注于处理账务和账户相关的任务，因此，在业务架构层面将进入“瘦核心”阶段。
于是，像代收、代付类的业务系统被拆出来了，像存款、理财、贵金属、基金代销等业务也被拆出来了。
每个业务的第三方都由业务系统自行对接，一个业务发起后，大致逻辑是：渠道->业务系统->第三方->核心系统->各种结果返回。当然，里面的顺序不同业务会有差异，在此大家能够理解主体意思即可。
这时，业务架构图大致变成了这种效果。里面会有很多很多业务系统，也会有很多外部合作机构。
同时，随着互联网渠道的兴起，像手机银行、网上银行、移动展业等互联网渠道应运而生。而银行的系统都是部署在绝对安全的“内网”，与互联网之间的传输交互，与传统的渠道直接通过内网连接的方式也有很多不同。
而且当银行的业务开始丰富、延展时，还会有很多第三方渠道、合作方，通过互联网模式将业务要素传入行内，因此，为了完成内外网的安全互通，银行增加了“接入网关”这个模块。
在资金交易方面，不仅有本行的资金处理，还有很多跨行交易的诉求。而核心系统主要进行本行交易处理，关于跨行交易，也有不同的系统承载。
于是，上面这张图又可以调整成这样。
紧接着，“瘦核心”阶段下的问题也逐渐体现出来，那就是业务系统太多了，像代收代付类的业务，一家银行有几十上百个都很常见。
每个系统都需要维护，而且很多系统之间存在不少共性，因此在系统建设层面存在很多冗余和资源浪费。
因此，“瘦核心”之后，银行的架构演变来到了第三个阶段：平台化。
将同类业务组合提炼，对外形成一个统一的产品，对内进行合并，并通过技术升级、标准流程制定等理念，提升开发、维护的效率。
所以，我觉得像光大云缴费这样的平台级产品，也属于这个阶段的产物。
各个业务系统都会产生很多业务数据，对于数据的处理，又拆分成了数据仓库、报表平台、客户统一视图（ECIF）等不同维度的数据类产品。
通过整合，将某类目标聚焦，既在架构上更清晰，又能通过技术和业务上的拓展性支撑未来多年的业务发展。
当然，上述介绍中提及的系统，仅是银行IT业务系统中的一小部分，还有很多监管类、管理类、风控类、场景金融类、银企合作类、资金类、资管类、同业类等等业务应用。
但从整个架构演变过程来看，具体业务差异不大，更多是基于科技发展、系统稳定、业务趋势等多个方面形成的“合理化迭代”。
本文也没有提到ESB（企业服务总线）的价值和接入模式，不过ESB作为非业务系统，在产品设计层面也不会有什么影响。
文章至此，介绍了银行IT架构变迁过程中的三个阶段：重核心、瘦核心、平台化，最终形成类似于下图这种架构模式。
不同的银行具体的架构，以及系统的名称都会有差异，但本质的结构和关联情况大同小异。
介绍完应用架构的变迁，最后聊一聊我对于理解整体架构这件事的意义。
我们若想在当下的架构里增加一个新系统，要考虑的要素还是蛮多的，因为任何系统都不是一个独立的个体，所以要考虑这个系统在业务场景中，和其他系统的联动性，还要考虑功能的复用性，以及功能的“载体”（即放到哪里）。
当下银行在新建系统中的考量和审核都比较严格，一是为了避免重复性建设，能够复用、能够整合的，依然本着复用和整合的目标。
二是很多系统上线之后，实际应用效果并不好，因此需要更加明确，更加具备可行性和业务价值。
三是近年来银行的经营效益也在经受很大的挑战，新系统建设的花费是一笔不小的数目，因此也不会像前些年那样顺利。
基于上述原因，很多情况下业务部门提出的新需求，可能就需要在现有应用中开发，或者将一个业务拆分成不同的模块，放到不同的应用中。
因此将对产品设计者提出新的考验，不仅要进行产品方案设计，还要跨部门沟通，多部门协作，做系统权衡。
另外，即便是同意了新建系统，这个新系统在设计过程中也要势必要遵循本行的开发规范、架构规范。
比如用户登录是否要对接行内的统一认证模块？密码加密是否要对接行里的安全密钥模块？线上的合同或者回执，是否要对接行内的电子签章模块？营销短信或通知短信，是否要对接行内的短信平台？
比如，和其他系统对接是系统直连，还是通过ESB，或者其他与ESB类似作用的服务总线？（因为很多银行不只有一个ESB，还有很多前置系统、网关系统，同样承载了系统间统一对接的作用）
再比如，系统是自建渠道，还是挂载到现有渠道？如果是挂载现有渠道，又要遵循渠道侧的设计规范、接入规范、安全规范。系统是否涉及资金交易，若涉及，资金交易通过哪个支付系统处理？系统产生的数据如何入仓？
还比如，我们需要某些数据，这些数据是从哪里获取？数仓？核心系统？卡系统？还是哪里？不知道，你得挨个问。
以上种种，还有未罗列的很多问题，都是在实际数字化推进过程中将要遇到的问题。
因此，银行业务的数字化，并不单纯是产品设计的问题，更多的精力是如何在当下的环境中，形成一个多方认可的执行方案。
我觉得，这些问题是未来影响银行快速实现数字化、数智化的最大“拦路虎”，更可怕的事，这些问题没有标准答案，没有可遵循的流程或制度，只能靠我们一次次的沟通、讨论、权衡，甚至妥协。
我从2015年8月参加工作开始，便莫名其妙的踏入了银行数字化转型的浪潮之中，八年间在全国几十家银行做过项目、售前，从测试的执行，到项目的把控，到需求的分析，再到产品的设计、方案的制定，越来越觉得大多数从业者缺少对整体应用架构的认识和理解，因此在执行中经常遇到“不可控”的阻碍。
随着工作的深入，我反而觉得所谓的“不可控”，其实是认知差和信息差的结果，当我们试着站在全局的角度，或者对方的角度考虑这些问题时，似乎也能理解了。
其实银行非常需要专业的产品经理来推动数字化战略转型。
而传统的银行从业者缺少互联网思维和产品思维，市场上的产品经理又缺少对银行业的理解，很多乙方的需求分析师也是半路转行，或者仅限于执行而缺少顶层设计能力。
因此，当下的银行，尤其是城商行、农信社、农商行，亟需补充专业的数字化人才。
最近一年，我翻阅了很多银行相关的书籍、文章，没有找到一篇真正适合银行IT从业人员、业务人员、产品设计者、新入行人员了解银行IT应用架构的介绍，因此将自己的理解汇总成这篇文章。
希望能够帮助更多的银行从业者，了解应用架构，进而更有效的推进金融领域数字化创新，写好未来“普惠金融”、“绿色金融”、“养老金融”、“科技金融”、“数字金融”五大篇章。
本文均为个人观点，与供职机构、合作伙伴无关。
我在参加人人都是产品经理2023年度评选，希望喜欢我的文章的朋友都能来支持我一下~
点击下方链接进入我的个人参选页面，点击红心即可为我投票。
每人每天最多可投30票，投票即可获得抽奖机会，抽取书籍、人人都是产品经理纪念周边&起点课堂会员等好礼哦！
投票传送门：https://996.pm/7l9po
专栏作家
不想延期，公众号：不想延期，人人都是产品经理专栏作家。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。