在以银行、电信为代表的大型企业中，借助于IT系统的不断建设和改进，不断提升企业面向客户的服务效率和业务创新能力，以及提升内部的管理效能和业务分析能力，可以说，IT系统已经成为企业日常经营、管理的重要手段。在长时间的建设过程中，这些企业形成了形形色色的各类系统，使得企业中无论是高层管理者，还是具体的业务办事人员；无论是运营生产部门，还是行政人事等内勤人员，都不同程度依托于（甚至于围绕）这些IT系统开展工作，由此可以推断：IT系统的易用性、使用效率、IT系统对业务运营管理和创新的支撑能力、IT系统之间的互动能力、IT系统的灵活性、IT系统建设和调整的快速性，对企业的经营管理有着越来越大的影响。

然而，由于长期以来，IT系统主要以业务条线或者职能领域的驱动方式进行建设，建设的时间阶段、建设的模式、开发的团队、采用的技术路线等不同，随着这种应用建设模式的持续，系统越来越多，很多企业人员在工作过程中，需要使用或维护多套应用系统，对于这些系统的使用者和建设维护者而言，也带来了越来越多的挑战和问题，以下我们以一些具体场景来深切感受这些挑战和问题：

场景一：老陈是某家大型银行的一位业务主管，老陈每天通过银行的IT系统处理各种数据和一些工作任务，这些工作包括在CRM这样的系统里面审批客户的工作；在办公系统里面去审批下属员工的请假或财务报销，在信贷系统里审批客户的贷款…..这些工作分布在不同的应用系统中，老陈必须打开每套应用系统的界面来查看和处理，意味着如果老陈某天忘记了登录其中某套系统，而这套系统刚好有一个很重要的任务的话，他有可能在这一天就忽视了这件重要的工作，相反，也可能他登录到了一个系统，却发现这个系统里面根本就没有他的任务，白白浪费他一定的时间，分散他的精力。

场景二：小雨是某家大型银行几千名信用卡客服人员中的一员，她在工作是接听客服电话帮助客户办理业务，查询信息或者记录客户的咨询、投诉信息，这些工作需要不同的IT系统的支持，例如通过运营平台发起一个后台人员处理的联系单；通过知识库系统查询客户关心的业务知识；通过积分系统查询客户积分；通过帐单系统查询账单明细和总账，等等。由于这些功能是由不同的应用系统提供的，而这些应用又是在不同的时期，由不同的开发团队开发出来的，因此需要在不同的应用之间进行频繁切换，而且应用之间操作风格的差异性比较大，很多功能鼠标点击的层次比较深，导致对客户的回复响应比较慢，工作效率也比较低。

场景三：小张是某家大型银行的一个IT工程师，他是一名J2EE的高手。小张在IT部门负责五套系统的维护工作，包括这些系统日常的日志处理、备份、系统的监控，或者说这些应用的Bug的修正，或者增补一些小的功能。这些系统尽管都是他所熟悉的J2EE应用，但是每套应用系统使用的J2EE框架几乎都不一样，技术的规范也不一样，维护的工作量特别的繁重，他一天到晚被动地忙于应付这些工作，并经常在加班，属于典型的“不求无功，但求无过”。

其实这三个场景是众多以提供客户服务为主的大型客户（如银行、电信等）的一个缩影。各种各样的应用系统构成了像蜘蛛网一样的应用网路，整个应用系统网络呈现出如下的特征：

• 系统技术架构非常发散，技术规范不统一，维护代价都很高，系统内部的模块耦合性太强，功能与数据交织，修改的复杂度很高，对业务部门的变更响应比较慢
• 在系统的使用者看来，如果一个人使用多套应用系统，在操作过程当中需要不断的切换，而且各个应用系统操作的风格差异很大，点击层次太深，培训的成本都很高
• 很多的应用采用了流程引擎实现，流程会产生任务，这些任务存在于不同的应用中，导致像老陈这样的业务人员需要登录不同的系统处理属于自己的工作任务

面对这些遗留应用的问题，我们可以采取整合的技术来进行改善，例如采用Portal技术实现门户整合，采用统一认证、单点登录技术实现应用的一次登录，但这种整合方案是事后弥补型的，代价较大，而且只能改进部分的问题，而新的业务应用还在不断的建设，是不是还要重复昨天的故事呢？

什么是“One应用”呢？简单来说，One应用就是让企业应用系统的使用者和建设者只感受到一套应用的存在，使用者感受到的One应用是“统一的应用入口”、“集中的操作菜单”、“集中的工作任务”、“风格一致的操作界面”；建设者感受到的One应用是“一致的技术架构、标准的技术规范、统一的应用平台”、“松耦合、模块化、组装式、增量迭代的开发模式”、“即插即用、可配置、分布式部署和维护模式”。

即插即用的“One应用”解决方案

确切地说，“One应用”是一种面向新应用开发的模式，在具体的用户场景中可以演化为不同的解决方案、解决不同层面的问题，既可以面向于全企业的IT系统，也可以面向于某个业务域（项目群）的系统（例如电信行业的BSS、或银行的信贷及风险领域、或企业的内部管理系统领域）。在“One应用”解决方案中，主要面向于管理类的系统，随着银行核心系统的趋向稳定，管理类的应用是银行IT建设的重点，而且是长期建设、持续演进的，管理类的应用涵盖范围广泛，包括客户关系管理、资金管理、风险管理、信贷管理、资产负债管理、审计管理、人力资源管理、办公自动化等等，由于系统繁多，是“One”应用解决方案非常合适的领域。

“One”应用解决方案主要包含两大部分：企业应用中心，统一应用平台。我们还可以用一个通俗的例子理解一下“One应用”解决方案：企业应用中心可以理解为电视机和遥控，观众无论看哪个频道，都是通过遥控选择，并通过电视屏幕观赏，但每个电视频道由不同电视台提供，一个电视台的频道可以理解为一个应用系统，频道是没有实际意义的，只是一个抽象概念（就如图一个系统也是一个抽象概念），只有频道的电视节目才是观众所需要的，而电视节目则好比是应用系统的模块，电视台节目的制作播放平台就好像“One应用”解决方案的“统一应用平台”。“One应用”解决方案的架构如下图：

 
在这个架构图中，企业应用中心面向于解决应用系统使用者的问题，包含了统一企业桌面、集中工作平台、集中任务中心三大部分，以下是三个组成部分的功能与作用：

统一企业桌面：实现信息门户、单点登录、统一认证，并建立企业应用系统的UI标准和规范。通过这个功能，用户不再需要记住所使用的每套系统的地址、用户和口令，不需要在使用多套系统时多次登录，而且用户界面一致，没有不同应用之间界面风格明显的差异。

集中工作平台：提供对应用、功能、权限、角色、用户、组织（机构、部门、岗位等）的统一管理和授权；实现菜单的集中展现、操作权限控制。通过这个功能，用户不需要知道自己在哪套应用中拥有什么权限，所有能操作的权限集中体现在自己的菜单中，无需关心后台是哪些应用提供的，操作方便，效率更高。

集中任务中心：提供集中的工作任务台，无论是来自OA系统、客户关系系统，还是信贷系统的任务（或信息），都集中呈现在待办任务列表（或个人信息列表）中，点击任务项，直接进入任务处理的界面（界面仍然由相应系统提供，但使用者感受不到）。通过这个功能，用户无需分别到各个应用中去查看和处理自己的任务。

架构图中的统一应用平台，则是One应用解决方案的技术基础，面向于解决应用系统建设者的问题。试想，如果对于接入应用缺乏统一的标准或规范，实施起来将会非常复杂，一方面，在应用与企业应用中心之间要建立接入的标准，确保通过企业应用中心的集中工作平台提供的菜单能够访问到应用中的具体功能，或者应用中产生的任务能够推送到集中任务中心，并通过任务中心的任务调用到应用中的处理界面。另一方面，对于具体应用的开发而言，可能是在不同的时间由不同的团队开发，如果缺乏统一的架构和相应规范，均需要独自考虑与企业应用中心的接入的问题，因此，有必要建立对接入应用的统一技术架构和规范。这还不够，仅仅有架构和规范，往往很难落实，最好的做法是通过平台和工具固化这个统一的架构和规范，同时也提升了开发的效率，以上就是统一应用平台的必要性和作用。

既然统一应用平台是“One应用”的必然组成部分，而统一应用平台的核心又是技术架构，那么，怎样的架构才是最符合“One应用”的架构呢？回答这个问题需要深入了解One应用的特征：在“企业应用中心”这个框架下，应用是逐步建设，逐步接入的，甚至应用的功能也是如此，而这些应用不可能部署在一台物理的服务器上，需要分布式的部署，这样就需要接入应用是模块化和可分布部署的，SOA的技术架构是满足以上要求的合适的架构，Gartner认为：“面向服务的应用是模块化的，并且模块（服务和客户端）是松耦合的、可共享的、分布式的和被分隔的文档化编程接口封装的。”Gartner同时认为：“要支持这种体系架构需要一个多功能的、基本的应用基础设施技术，在这种应用基础设施的技术上形成一个平台（或套件）”。

基于上面的认识，神州银行需要为“One应用”解决方案的实施选择一个符合SOA架构的应用平台，为各个接入企业应用中心的应用提供基于SOA服务的开发、运行和管理的功能。经过广泛选择和深入验证，最终选择了Primeton EOS Platform 6.0作为了统一应用平台。Primeton EOS Platform 6.0提供了符合神州银行“One应用”解决方案的SOA应用技术架构，如下图：

 
EOS提供了符合SOA技术标准的应用多层技术架构，为应用提供了清晰的层次划分，在提供各个层次图形化组装的基础上，也提供了传统的代码开发模式；同时，EOS提供了完整的应用开发环境，支持应用功能、业务流程、业务报表的一体化设计、开发和部署、运行维护，见下图：

 
重要的是，EOS平台中以构件包作为应用系统实施的设计、开发和部署管理维护的基本单元，构件包之间基于标准服务访问，构件包可以独立部署，构件包对应于业务模块，因此实现了业务模块的松散耦合与分布式部署。

由“企业应用中心”和“统一应用平台”构成了“One应用”解决方案，那么在物理部署时体现为怎样的关系呢？在IT的环境中，可能存在多台J2EE服务器，J 2EE服务器中运行EOS Server，由EOS Governor提供部署各个应用系统业务模块的功能，J2EE 服务器可能进行集群，同时也可能连接相应应用的数据库服务器。企业应用中心则是一台独立的服务器，同样也部署J2EE Server和EOS Server,集中工作平台和集中任务中心是基于统一应用平台开发的两个构件包，配合上Portal和LDAP服务器，构成了“企业应用中心”这样一个框架性应用，这样，业务系统可以注册到企业应用中心，通过单点登录技术和内置的权限控制服务实现基于URL的方式对各个应用系统中功能的访问，通过MQ（也可以部署ESB服务器，MQ作为接口模式）实现各个业务流程应用中流程任务的推送，部署图如下所示：

 
基于“One应用”解决方案的应用实施模式

完整的“One应用”的体系除了上面介绍到的有形的“企业应用中心”和“统一应用平台”外，还必须建立一套无形的规范：包括“One应用”的UI规范（可以抽象成模板固化到统一应用平台中）、应用接入规范、流程接入规范、应用开发规范，基于以上这个完整体系支撑业务应用的实施和部署、运行。

当有某个业务应用需要建设时，仍然按照以前的模式进行立项和需求整理和分析，在“One应用”体系下的差别主要体现在设计开发和部署运行阶段，并增加了应用和流程接入的阶段。

（一） 应用开发：面向业务模块或流程进行构件化、服务化、图形化的设计、开发组装，开发过程遵循相关技术规范，另外，无需实现权限管理模块

（二） 应用部署：当业务模块或流程实现后，部署时首先确定策略：是部署在已经接入企业应用中心的某个应用系统环境中，还是独立部署一套新的物理环境，或者是部分构件模块部署在已有环境中，部分部署在新的独立环境中，部署过程通过统一应用平台的管理监控环境以构件包的方式部署，并支持运行期构件包的版本控制

（三） 应用和流程接入：当功能或流程部署后，通过企业应用中心的集中工作平台完成对新的功能的配置，并将新功能作为权限赋予给相应的角色或用户；通过集中任务中心完成对新增加的流程的配置，并把流程启动的权限赋予给相应的角色或用户

完成上述工作后，新业务上线日，当业务用户像往常一样登录到企业应用中心，会发现自己的菜单中多了一些新的菜单项，点击这些菜单，出现的界面可以处理新的业务，但界面的风格和以往所使用的功能没有差异，同时，某些人的集中任务列表中，可能多了一些新种类的流程任务。这样，新的功能和流程在“One应用”体系中自然和谐的运转起来。如下图：

 
神州银行在实施完“One应用”的解决方案后，IT的建设模式和IT系统的体验模式都得到了非常大的改变，在完成“企业应用中心”这个框架性应用后，目前已经接入到企业应用中心的应用数量有5个以上，业务流程40个以上，的确获得了较好的效果，对老陈这种使用者来说，操作体验更好，工作效率大大提升，对小张这种IT建设和维护者来说，业务模块松耦合，使得系统灵活性更好；系统实现分布式部署，集约化管理，提升了业务模块部署的横向伸缩性，使得系统运行可靠性更高；当然，这还只是开始，未来在接入更多的应用系统后，综合效用会体现得更明显。有个不可回避的问题是：目前没有采用统一平台实现，没有遵循接入标准的应用和“One应用”体系是什么关系呢？仍然用前面提到的电视机例子来说明：现在电视机都提供了很多接口，可以接入DVD，VCD等其他系统，同样道理，企业应用中心整合了Portal平台，可以实现对异构遗留系统的界面整合和单点登录，当有一天，这类系统生命终结时，将采用新的架构实现后，接入到企业应用中心。

一方面，符合“One应用”体系的新业务开发在持续进行，不断丰富之中，另一方面，神州银行的“One应用”解决方案的内容也在丰富和扩充，基于“One应用”体系的企业服务治理平台、构件库管理平台、知识管理系统也逐步纳入到规划和建设范围，可以预见，“One应用”解决方案将带给神州银行IT建设深刻的变化，并越来越明显的体现其价值。

评论　共 0 条