SOA方法—商业银行应用架构变革之路

1、银行IT架构体系发展
随着金融业的发展，银行经营模式正处于不断的变革中，银行业务办理由各部门独立运作向多部门协作的流程银行转变；银行管理由粗放型管理转化为精细化管理转变，从行政化的管理体系转向扁平化、集中作业式的管理体系发展；由过去以交易为中心、以产品为中心，朝着以客户为中心，提升客户满意度的方向发展；由以传统业务为基础，向以市场为导向，发展特色银行、精品银行转变；积极进取拓展新客户、新市场；实现快速的金融产品创新，实现产品多元化，特色化，提升银行品牌形象。。。。可以看出，金融行业越来越向着金融产品的工业化发展，在金融服务的产品化、标准化、差异化方面，在金融产品生产过程所要求的产品组件标准化、流程变革敏捷化、风险管控精细化等方面，都越来越呈现出与制造业相类似的特点。构建一个能够成功的适应业务快速发展变化需要，从而提供出色的客户服务的业务体系，将成为银行的核心竞争力所在。

为了适应银行业务发展这种趋势，银行IT架构也走过了相应的发展历程，呈现出螺旋式发展的轨迹：
90年代，主要的银行业务纷纷完成了信息化，建成了各种不同的业务系统（如储蓄、对公、卡、中间业务。。。），这些初步的银行信息化建设，大大提高了业务办理效率。但同时，各个业务系统之间相互独立，互相之间仅有少数的记账、查询的接口，形成了很多的信息孤岛。众多的信息孤岛，带来了业务之间的隔阂和信息整合的难度。
随着硬件和网络的发展，大而全的综合业务系统开始出现，特别是中小规模的银行，选择同一个厂商用一套系统来完成大部分的银行业务成为了主流，围绕着核心系统，建设了信贷系统、国际结算、电子渠道等外围系统，外围系统一般通过直连或大前置的方式接入核心。这种以核心系统为中心节点，外围系统围绕着核心建设的系统架构模式虽然实现了数据的集中管理，也能满足当时的主要业务需求，同时在业务管理和IT管理方面也相对简单；但随着银行竞争程度的不断加剧，银行业务变革不断加速，业务需求呈现出爆炸性的增长，业务流程化要求、服务多样性要求、管控精细化要求等对IT都提出了更高更多的需求，这个时候，用一个系统一种技术实现所有需求，成为了不可能完成的任务。这种问题集中表现在：经过多年的运行之后，很多银行的老核心系统现在已经步履蹒跚，由于它包罗万象又缺乏足够的弹性，导致每个新需求都需要对老核心加以改造才能实现，而大部分的业务又都耦合在老核心一个点上，老核心牵一发动全身，任何修改都可能造成整个系统不可预知的结果。。。老核心系统已经成为了银行IT系统的瓶颈，甚至到了谁都不愿改不敢动的地步，成为了业务发展的拦路石，同时，也为系统的安全稳定运行埋下很多隐患。大而全的系统设计理念逐步被证明行不通，需要寻求新的发展策略。

在摒弃了大而全的系统建设思路之后，根据各业务条线的发展需要，采用最合适的技术、最合适的软件产品来实现不同业务、不同服务的需求，成为了一种必然的选择。在过去十年中，全球化的势不可挡，在金融业、IT业同样得到深刻的体现。现在，对于每一种的银行业务，如信贷、信用卡、财富管理、私人银行等，在全球范围内，都有非常多的采用不同技术实现的高度专业化的优秀软件产品可以选择，这些软件产品各有优势，能在不同维度上满足不同银行对于业务、服务的不同需求。对每一种不同的业务，除了银行自行建设之外，在全球范围内选择一套最适合自身竞争力需求的软件产品并加以实施，无疑成了银行家们的最佳选择。在这种选择的前提下，如何使得很多的在每一个行业细分领域的优秀软件能很好的协同工作，从而发挥各自的优势，使不同系统对业务的支撑能形成合力，从而真正体现银行整体独特的竞争力，将成为银行IT发展战略中的关键问题。

2、SOA对银行应用带来的变革
简单回顾软件技术特别是软件工程的发展历程：从面向过程的能够编码方法，到面向对象的设计思路、再到现在面向服务的设计理念，其核心是不断的提高软件复用度，不断的提升软件生产效率。
所谓的面向服务架构SOA，它不是一种技术，更像一种哲学，是人类在探索现实世界的过程中，随着认识的深入，对现实世界不断的进行抽象和建模的一种思想方法。通过SOA，把现实世界的各种实体（组织、客户、存款、贷款、。。。）抽象成一个个独立自洽的“服务”，并对这些实体与外部其他实体之间的关系进行界定和清晰的表述，通过服务识别-分析-设计的建模过程，形成这么一组服务：这组服务是某个特定的现实世界的映射，在这个映射中，现实世界及其活动通过服务自身和服务之间的互动得以体现，从而使服务模型得以很好的适应和表述现实世界的演化过程和演化结果。在这个模型里面，每一个服务独立的存在着，对外提供公开的服务界面，服务与服务之间通过这些公开的服务界面进行沟通，沟通的结果将反馈到服务本身；同时，每个服务自身的运作机制并不影响其他服务，当某个服务自身发生变化时，只要其对外提供的服务界面不变，对外部系统都将毫无影响
-- 这正是现实世界中不同事物（如人与人）之间并存协作的真实写照。

可以看出，SOA理念正适合用来解决上述银行业务技术发展过程中所遇到的关键问题。回顾一下我们的问题：如何构建一个由不同产商不同技术的软件所组合起来的银行整体架构，在这个架构体系下，所有的软件能协同工作，发挥出各自的优势，对业务的支撑形成合力，从而真正体现银行整体独特的竞争力？
为达成这样的目标，我们从纯粹业务的角度出发，采用SOA方法对银行服务体系进行建模：
1、首先从业务层面出发，梳理确定银行的业务体系，在各个业务条线设计出相应的银行产品以实现这些业务竞争力，形成业务需求；通过服务识别过程，形成一组银行服务集合；
2、将业务需求加以细化，分析服务的内容、服务的过程、服务的风险点等等，通过服务分析，清晰定义了服务本身的特征和服务的边界；
3、将服务进行封装，定义服务对外的接口界面：该业务将如何被使用，该业务如何为不同客户在不同渠道上提供服务，在业务流程中与上下文其他业务的关系等等；通过服务设计，完成服务的封装与发布。
不同服务可以加以组合。在基础服务定义好后，可以配置不同的服务流程，实现不同的服务组合，形成更多更复杂的银行服务，以适应业务的多样化和个性化需求。
随着业务的不断发展，这个建模过程无疑是迭代式的，迭代建模的结果形成一组被良好管理维护的服务，我们称之为银行的服务规范体系，通过服务规范，银行的业务体系将得到越来越明确的描述，银行的核心竞争力也得到越来越明显的体现。
在服务规范体系建立起来后，根据银行业务的发展规划，制定IT建设的路线图，逐步实现服务规范体系所定义的各项银行服务 -- 在建设的过程中，可实现上述的想法：对于某一个或某一类服务，要么在全球范围内选择最适合银行服务规范所需要的软件产品，要么自行设计建设新系统或对现有系统功能进行封装重组，从而实现银行服务的落地 -- 服务落地过程即体现为软件系统的实施上线过程，并为银行带来实际的收益。

由于首先定义好了服务规范，不同的软件系统面向的都是同一套服务，大家都讲同一种语言，沟通的障碍消失了– 软件与软件之间，服务与服务之间，都只需要知道这个银行所发布出来的服务，用同一种服务规范即可以沟通，沟通过程中完全不需要了解对方系统如何实现、如何运作的细节，更加屏蔽了不同技术平台所带来的技术差异-- 相互之间只须关心以服务界面的形式所存在的业务语言 -- 这种系统架构状态，我们称之为松耦合的架构，是SOA的核心理念所在。
当业务需求发生变化时，首先考虑调整服务本身的参数来满足，然后考虑调整服务流程、服务组合的方式来满足，在服务重组仍无法满足需求的情况下，最后再考虑升级或替换该服务背后对应的软件系统（称为服务提供者）来实现。只要保持服务规范服务界面的稳定，任何服务系统的升级改造，对整体系统的其它部分将没有影响或影响被限制在非常小的可控范围之内。而服务层面上的重组和复用，大大提升了软件系统的灵活度，也充分保护了已建成的软件系统的投资，大量的银行存量系统可以通过服务封装和服务重组的方式重获新生，融入新的SOA架构体系之内，成为银行服务体系的一环。通过这种方法，在保证了整体系统架构的弹性的同时，也保证了多种异构系统并存的复杂业务系统的得以长时间的安全稳定运行。

3、SOA“落地”的技术实现-ESB
剩下的问题，是采用一种灵活的集成方法，将不同时期不同产商不同技术的软件轻松进行的松耦合连结即可，这样的一种平台，提供非侵入式的方法实现异构系统之间的集成，每个系统将自身所提供的服务发布在这个平台上，同时通过平台调用其他系统发布的服务，这样的一种平台我们称之为企业服务总线ESB。ESB是SOA架构体系的基础部件，提供了银行整体架构向SOA方向演化的可能，是银行SOA架构落地的最佳实践。需要强调的是，在这个架构体系下，所有业务都将经过ESB，ESB将替代传统的核心系统成为银行架构的核心
– 因此，ESB在实现异构系统集成便捷性的同时，必须重点关注ESB平台本身的系统性能、安全和稳定。