2006年8月，交通银行成功完成数据大集中工程，标志着交行的IT建设迈入了新的阶段，原来以分行为主体进行的IT系统建设和维护，将全面转变为以总行统一的建设和管理维护，在集中数据和IT系统的基础上，交通银行将通过管理信息系统的规划和建设来实施银行流程的重组和优化，并对银行的业务模式、营销模式和管理模式进行深层次的整合，提高经营管理水平，以适应中国加入WTO后日益激烈的金融市场竞争环境;同时需要构建与市场需求、技术发展趋势和交通银行发展相适应的IT体系，整合分散的科技资源，发挥集约化经营的效益。

　　伴随这数据大集中的逐步实施，各个业务部门的MIS系统建设需求源源不断推到了交通银行开发中心的开发部门，由于交行开发中心的人员规模有限，无法完全自主开发来响应业务部门的需求，起初，只能是借助外协厂商的力量来建设各个系统，开发部门人员主要起着项目控制、需求沟通、质量控制、系统维护的作用，在这种建设模式下，随着系统建设越来越多，开发部门感觉到越来越多的困惑：

　　大集中完成后，大量的管理型应用迫切需要建设，系统建设周期要求都非常短，如何有效的保证系统实施的速度和质量?

　　随着企业运营对IT的依赖越来越深入以及市场对上市公司管理内控要求越来越高，导致业务和管理系统的复杂度也越来越高，IT部门人员疲于奔命在新系统实施和老系统的维护之中，如何改变IT部门被动满足业务要求的局面?

　　不管是系统实施中，还是系统维护中，业务部门对系统的要求在不断的变化，而僵化的系统架构往往无法跟上变化的脚步，IT部门如何能够通过建立更加灵活的IT架构，以更好的适应这种不断变化的要求?

　　多个开发商带来了不同的技术架构，而且项目管理水平和人员质量参差不齐，IT部门如何提高项目实施过程的管控和系统维护的管控能力，同时保证各个系统之间良好的整合能力?

　　各个应用在不同时期由不同团队基于不同技术建设，形成了不同的应用“烟囱”，业务用户在不同系统之间需要频繁登录和切换，信息分散，操作不便，如何通过IT模式的转变，提升操作用户体验和工作效率?

　　金融行业同业竞争激烈，而交行IT部门人员规模中等，如何利用有限的人力资源实施和管理和大行差不多数量规模的应用?

　　寻找适合交通银行的MIS建设模式

　　这些问题，在交行IT部门看来，均归属于IT建设中的非功能性问题，解决这些问题的重要手段是收缩技术路线、统一技术标准和规范、采用平台化的架构、建立松散耦合的系统架构。基于这种公识，交行IT部门推动了平台架构选型的工作，当时，在选择平台架构的思路上，经历了三种不同方案的实践过程：一、购买成型的套装软件;二、自主研发统一的架构平台;三、选择第三方成熟的商业架构平台。

　　针对方案一，交行在一些重要应用中选择了购买第三方的套装软件，通过实施，发现套装软件在带来一些成熟的业务实践的同时，也带来了僵化的系统架构，导致了当交行业务要求与套装业务模式出现差异时，系统修改复杂且工作量巨大，同时系统的效率非常低下。交行人力资源系统的项目经理描述说：“当时采用国内某个大型套装软件公司的ERP实施交行的HR系统，当某个需求无法满足时，实施公司的人员说：‘我们的软件就是如此，我们无法修改成你需要的模式’。更加让人无法忍受的是系统的效率，每次到了月初计算分行工资的时候，操作人员在点击了工资计算的按钮后，去吃了一顿晚餐回来发现还没算完，于是又去洗了个澡……”，通过采用套装软件的经历，交行认为套装软件并不是非常合适交行，因为交行的应用需求与套装软件功能的重合度不是太高，而且系统的变化比较快。

　　针对方案二，交行IT部门的架构师团队试图整合一些开源框架，建立交通银行自己的开放平台架构，经过评估，发现自己开发和维护一个技术平台需要比较大的时间和人力的投入，交行IT部门的人员规模是无法很好保证去实施的，即使加大投入做出来一个基础的版本，但也存在着平台维护的成本会比较高，人员流失风险大，以及技术团队必须有较强的技术获得能力，保持平台与技术发展方向的同步。更重要的问题是，自主维护这样一个技术架构平台，显然与交行IT部门的核心职能是冲突的。

　　于是，最终的方案集中在了对第三方的成熟架构平台选型上，选型把平台架构先进性、灵活性、开放性、扩展性、性能、稳定性;业务的快速构建、适应业务变化能力;基于平台实施系统的可管理性等作为主要的评估标准，对国内外一些应用架构平台进行了验证和评估，最终确定了选择普元面向构件的SOA中间件-EOS作为交行开放架构平台，承载交行MIS应用系统的建设。

　　普元EOS是基于J2EE平台、采用SOA和构件技术实现企业级应用开发、运行、管理、监控、维护的SOA中间件平台，该平台将应用的层次划分为运算、构件、服务、流程、展现等多个层次(见图一)，使应用系统结构松散耦合，同时，EOS通过图形化的构件单元作为应用系统的基本组成元素，使应用系统可以快速高质量的搭建，建成的应用系统具有较强的可管理可维护能力，并拥有较强的需求变化响应能力;EOS平台还提供了功能强大的工作流引擎，可以很好支撑管理流程的流转;另外EOS提供了良好的构件积累机制，可以持续积累软件知识财富。

　　(图一：基于EOS中间件的应用层次逻辑架构)

　　交通银行MIS建设的SOA架构形成和实践经历

　　在确定了EOS作为技术架构平台后，为了降低选择风险，交行首先在有限的项目中进行了尝试，选择了完成大集中后最紧迫和最重要的客户综合信息系统(CIIS)以及会计台帐系统作为试点项目进行了试用，取得了不错的效果，并且获得了以下的结论：

　　项目建设的周期大大缩短，例如CIIS系统一期只花了4人3个月的时间，工作量节省了40%左右

　　同一个项目在不同期中引入了不同的开发团队，实现增量开发，提升了项目实施的控制能力，例如CIIS系统建设了三期，分别由不同开发商的团队承担，项目开发的过程和规范得到了统一，知识的转移和承接得到了很好的体现

　　采用构件化的方法使得应用能够更快响应业务的变化，项目维护方便。原来一个业务需求变化平均需要2周时间，目前系统的变化平均5天就可以响应

　　系统运行稳定可靠。开发中心某主管副总曾说过，相对于其他的J2EE系统，CIIS应用系统自上线后，从来没有过因故障导致的宕机报告

　　成功的实践坚定了交行IT部门的信心，为了更大程度上发挥面向构件架构平台的价值，建立组织级的效能，提高项目之间的复用性，从2006年开始，交行基于EOS进入了规模化实施的阶段。并对大规模的实施进行了规划，以统一技术架构(EOS)为基础，做到了多个统一，包括：

　　和开发中心认证CMM3结合，统一MIS应用开发过程和项目管理方法和文档规范;

　　统一规划并实施了公共构件库(例如权限管理、机构管理、业务码表管理等);

　　统一了交行J2EE应用的界面规范和模版，使得业务部门用户的操作习惯和用户体验更加一致，减少培训成本;

　　建立了统一的构件规范和复用机制，使得各个项目组之间的复用成为可能;

　　同时，为了保障统一规范得到人力资源能力的保障，交行要求各个外协厂商的技术人员必须经过EOS平台的认证，并在项目建设要求中明确选择EOS平台作为应用的技术架构平台。

　　随着EOS规划级的实施，交行基于EOS平台的应用项目开发一时风生水起，从2006年开始，相继启动了10多个项目，包括人力资源系统、内部评级系统、财富管理系统、资产风险系统、资金管理系统等等(见图二)。

　　(图二：基于SOA中间件实施的应用一览)

　　规划级实施的最重要特点就是“统一规划”，因此IT部门结构和项目组织均需要体现“统一规划”下的特征(见图三)：一、开发中心的项目管理部结合SOA和面向构件的特点，制定了相匹配的项目管理方法、制度和规范，用来约束和指导各个应用项目的项目管理过程;二、设立IT规划组织(虚拟)，由开发中心架构师、高级开发人员组成，负责制定基于SOA中间件下统一的技术规范，如设计规范、开发规范、页面规范等，用来约束和指导各个应用项目的具体开发，还负责规划和实施和管理各个项目公共的构件库，如机构、权限管理等，另外，IT规划组织还承担对各个应用项目实施后提交的公共构件的审核职能;三、当某个应用项目启动并确定开发商后，开发商的项目人员、开发中心的人员、厂商的支持人员共同组成项目组，项目组按照统一的项目管理方法，复用公共构件库，按照统一的开发规范实施应用项目的需求，其中开发中心负责进行业务的协调、需求的梳理和确认，开发商项目团队负责需求的分析、设计和基于构件的实现，厂商支持人员负责技术咨询，包括设计开发咨询、系统实现及规范性走查、上线支持、应用调优等。这种项目组织结构，有力保障了项目质量，降低了项目实施风险，加快了项目实施的速度。

　　(图三：规划级模式下的IT组织结构图)

　　作为企业应用的架构平台，EOS很好的利用分层和构件技术解决了应用系统松散耦合的问题，而且通过EOS实现的业务构件和流程，可以作为服务被第三方系统调用，当然，也可以将第三方系统的服务封装成本应用的构件进行调用，这种模式，很好的体现了SOA架构的特性，利用这种特性，通过交行部署的ESB体系，将各个应用连接成企业级的SOA应用架构(见图四)，这样，通过EOS构造SOA的服务，从而把系统内部的模块关系由紧密耦合变为灵活可变的松耦合，通过ESB把系统间的关系由紧密耦合变为灵活可变的松耦合。

　　(图四：基于EOS、ESB、MQ的SOA架构模型)

　　交行的应用系统很少是孤立的，在交通银行的SOA架构模型中，MIS系统与主机交易或其他业务系统的交互通过ESB实现，这样避免了数据、接口模式、和协议的差异，也在MIS系统和业务系统之间建立了一道安全屏障。为了降低复杂度，保障可靠性，应用与ESB的接入方式采用了MQ方式(见图五)，采用该接入方式时，基于EOS开发的应用程序(服务)采用JMS与WebSphere MQ队列进行通信，应用程序的队列管理器与WebSphere Message Broker的队列管理器之间采用Channel方式进行连接，充分利用MQ的可靠传输功能，并可利用MQ Cluster功能实现WebSphere Message Broker的群集，达到纵向扩展和负载均衡。

　　(图五：应用与ESB之间采用MQ的接入方式)

　　交通银行MIS建设的SOA实践效果

　　在交行的SOA架构下，随着多个系统的成功实施，IT部门越来越感受到对IT实施和管理带来的价值，包括应用项目实施的周期和过程得到了比较严格的控制，应用的质量得到了整体性的提高，IT整体投入减少，系统之间的交互变得更加容易，流程开发更加快捷，开发中心、开发商以及平台厂商之间形成了良好的生态链。

　　更为重要的是，交通银行MIS系统的SOA架构对业务发展的作用愈加明显，通过良好的业务方案和IT架构的整合，能够较好支撑业务部门在流程、管理和业务模式方面的创新，例如在OCRM中，基于SOA的体系架构帮助系统实现了客户信息的360度整合，过去，客户信息是分散在各个业务系统中不能共享的，基于新的SOA架构实现OCRM系统则有效地解决了这个问题，客户经理可以通过OCRM系统，“一揽子”查阅目标客户的基本信息、产品账务信息、地址信息、联系信息、事件信息、资源信息、关系信息、风险信息、统计分析信息等，而所有信息均以客户号为标识集中显现，真正实现了“以账户为中心”向“以客户为中心”的转变，这种转变，同时又转化为服务质量、处理效率的提升，当OCRM上线后，每日处理的贵宾用户申请相比之前增加了5倍。

　　例如在资产风险管理系统中，通过ESB平台跨系统整合能力和EOS平台提供的流程引擎，实现跨机构、跨部门和跨应用的资产风险监控流程和风险管理，对于凡属对全行资产进行风险管控的功能，均纳入资产风险监控管理系统，同时，由于采用EOS平台的构件化开发方法，项目团队可以较好的实施专业化分工和迭代式开发，加快了项目实施进度，系统2007年3月上线后，系统有效减轻了基层工作压力,特别是风险监控条线、资产保全条线的工作压力，提高了全行资产风险管理、资产风险监控工作的主动性、时效性和准确性，实现风险关口前移，在07年，各分行运用系统严格执行风险过滤流程，通过系统采集到的风险信息，在行内检索出违约客户1000多个，涉及金额将近5000亿，针对客户的风险记录，避免了60多亿高风险授信的发放。

　　通过实施面向构件和SOA架构的MIS系统建设战略，三年来，交行的IT建设取得了较大的成绩，正因为如此，交通银行于07年底一次性申请了包括人力资源系统、资金管理系统、资产风险管理系统在内的三个项目的科技成果奖。当然，更重要的是，这种建设模式，对银行业务的支撑与推动作用逐步显现，为交行从部门银行逐步转向流程银行奠定了较好的基础。

　　交通银行MIS系统SOA实践的未来之路

　　可以说，交通银行MIS系统在实施SOA战略的道路上尝到了甜头，但SOA的实践是长期的和不断深化的，SOA架构带给企业IT建设的价值，也将是不断深化的，因此，交行为了进一步深化使用，挖掘基于SOA架构和EOS平台的优势，在结合具体应用的面向构件SOA实践路线上，进入到回归级阶段，主要体现为如下特征：

　　业务服务的管理：目前ESB只是管理了各个应用系统之间交互所需要的服务，还没有做到企业服务的集中注册和管理，未来需要将各个应用中的服务分离出来，注册到ESB中，另外，还需要将业务功能抽象到业务构件的层次，真正实现IT资产和业务服务的集中管控;

　　构件库和知识库的建设：随着越来越多的应用开发，积累的构件也越来越多，这些构件的通用性和功能需要进一步整理和完善，并需要进行统一的管理，同时，伴随着构件的开发过程，积累了相关的使用经验和实现方案，为此，在回归级阶段需要建立构件知识库系统;

　　项目经验值的获取：由于各个项目的技术架构一致，项目方法一致，因此项目的工作量以及资源投入的汇总有助于计算出项目的生产率，而这个生产率通过多个项目的积累加权后，可以作为新项目工作量和投入的评估标准;

　　项目管理方法的持续改进：规划级定义的项目方法，通过多个项目的验证，需要进一步进行改进，不断提升项目的管控能力;

　　项目人力资源配置的优化：目前，交行在实施新的应用系统时，呈现出新的变化，即采用人力外包的方式，在一个项目组可能招纳多个具有EOS认证资质的公司人员，一方面充分发挥了各个开发公司的优势，一方面也避免了某个应用系统被某个开发商绑定的局面。

　　交通银行MIS系统建设的SOA实践之路是一步一步踏踏实实走出来的，而且已经走出一片风景线，相信，在这种稳健而又不断创新的风格下，未来的风景将更加美好!