|银行烟囱式系统难题,如何通过应用集成方式来解决?


应用集成是解决各个系统之间信息共享中最基础和最重要的一步 。 我国的商业银行都拥有繁多、复杂的应用系统 , 重复开发的情况严重 , 而且不能很好地跨系统共享数据或功能 , 不利于金融创新能力的提升 。
本文主要介绍了应用集成的发展阶段 , 和如何运用集成技术与方式解决系统的烟囱问题 , 以及相比较之下的优点与局限性 。 还请各路专家批评指正 。
本文适合系统集成人员、应用开发人员或接口组人员阅读 , 能扩展一定知识面、实现个人技术&业务能力的沉淀和提升、从而设计出更好的集成解决方案 。 在实际工作中 , 会遇到各种各样的问题 , 对开展工作的方式方法或套路还在梳理中 , 暂不做介绍 。
此文的输出源于在工作中的一些思考和经查阅资料后而得出的总结 , 文章内容不代表公司观点 。 在文末有列出参考资料 , 方便对某个分支感兴趣的同学 , 自行深入学习 。 同时也希望和更多的朋友一起探讨和分享 , 或直接在留言区说说你的看法 , 一起成长 。
一、应用集成的基本概念和发展阶段
1、 基本概念
应用集成是将基于不同平台 , 用不同方案建立起异构应用集成的一种方法和技术 。 对银行信息科技而言 , 不仅能够充分发挥各单一应用的价值 , 而且还能使银行的整体运作效率得以提高 。
在《银行信息系统架构》一书中 , 关于应用集成是这么说的:“从全行角度看 , 银行IT系统是一个有机的整体 , 需要不同应用之间的信息交互和服务协同 , 那么就要对应用进行集成 。 ”
对应用集成的结构化描述叫应用集成架构 , 可以结构化地描述多个应用之间的关系 , 具体的例子在下文中会细讲 , 先一起来看看发展阶段吧 。
2、 发展阶段
了解应用集成不同发展阶段的定义 , 有利于银行认识自己 , 找出差距 , 更好地有针对性的实施IT规划;有利于从业人员对本专业形成正确的认知;有利于让我们自身知识体系更加丰饶和健全 。
如何划分我国银行IT系统应用集成的发展阶段 , 有多种说法 , 没有一个业界公认统一的标准 。 同梁礼方老师说的一样 , 不能用时间点来统一定义 。
因为不同的银行 , 成立的时间不一样 , 应用系统集成的起步时间自然不一样 , 并且后来成立的银行可以参考前面银行IT建设的经验 , 虽然起步稍晚 , 但发展相对会快一点 。
从银行的应用集成架构模式来梳理 , 应用集成的发展阶段主要可以分为网状型架构、轮状型架构、总线型架构、API平台和云服务总线 。
1)网状型架构
网状型架构又称为''点对点连接'' , 指不同的应用间处于完全平等的地位 , 系统间很少有统一的接口规范以及报文格式 , 任意两个应用间都可以互相连接或服务调用 。
网状型架构实现了简单、基本的信息交互和数据传递 , 优点是不必太多关心其他应用的影响 , 交易路径简短 , 总体效率高 。 其缺点也是显而易见的 , 功能分散、互联复杂、不易管理、缺乏可伸缩性 。
比如 , 文件/消息格式、安全策略等集成逻辑是硬编码到应用中;再如 , 对IT服务没有形成统一管理 , 检索和发现功能困难 , 从而阻碍了资源的重用 。
|银行烟囱式系统难题,如何通过应用集成方式来解决?
本文插图

从上图可以看出 , 当时系统间的关联关系非常混乱 , 整体呈现为网状结构 , 像蜘蛛网一般 。
这是因为在系统设计开发时 , 没有考虑它们之间的互联 , 所以之后系统建设时 , 会发现有的外包采购系统与其他系统的报文结构都不一样 , 与这类系统对接时 , 需要把接口的报文全处理一遍 , 导致了很多重复的工作 。
随着银行信息化的不断深入、系统数据和数量不断增加 , 系统间的相互访问越来越多 , 越来越密切 , 系统的建设难度和改造难度也越来越大 。


推荐阅读