关键词：企业应用集成 业务整合 概念验证

1 EAI的基本概念和技术架构

1．1 EAI的基本概念

EAI（Enterprise Application Integration）——企业应用集成，最初字面理解为企业内部不同应用系统之间的互连，以期通过应用整合实现数据在多个系统之间的同步和共享。随着EAI技术的不断发展，认识它的内涵也越来越多，它已经被扩展到精力整合的范畴（Business Integration）。业务整合不仅要提供底层应用支撑系统之间的互连，同时要实现存在于企业内部应用与应用之间，本企业和其他合作伙伴之间的端到端的业务流程的管理，它包括应用整合、B2B整合、自动化业务流程管理、人工流程管理、企业门户以及对所有应用系统和流程的管理和监控待方方面面。对于要实施EAI的企业而言，EAI也是分层次的。对于如何划分和规范EAI层次的定义，业界并没有一个统一的标准，针对不同的企业，同样叫“企业应用整合”，其内容和层次可能就会存在一定的差异。对于各家EAI厂商，基于EAI理解的侧重点不同，也可以理解为不同的答案。

1．2 EAI的技术架构

1．2．1 EAI的四种类型

EAI有以下四种表现形式，形式逐渐复杂，难度逐渐加大：

数据集成：数据集成的目标是通过利用消息和数据转换工具进行集成，以一致、可重复的方式在数据库间安全、可靠地传输数据，使得企业的各种数据库中的数据是一致和同步的，从而建立企业范围的统一信息视图。

应用集成：应用集成是以数据集成为基础，利用集散（Hub）、星型或者总线等架构，使一个应用的数据和功能与其他应用的数据和功能协作。应用集成常常利用消息代理或者应用服务器，并需建立企业范围的应用接口模型。

业务流程集成：业务流程集成是以数据和应用集成为基础，按企业的业务流程来集成多个系统的数据和功能。业务流程集成不仅仅在系统间共享数据，而是进行企业级的数据管理。业务流程集成需要使用流程自动化的建模工具，并需建立企业级的业务模型。

外部集成：外部集成是指与客户、合作伙伴及供应商进行交互和整合。外部集成需要利用前面3个类别的EAI集成所建立的企业范围的应用，常常利用公共的网络集成设备（例如Internet），并利用XML等开放的数据标准。常见的外部集成包括B2B和B2C等。

1．2．2 EAI的六个整合层次

EAI涉及多个整合层次，任何的EAI导入都必须藉由外部协作、业务流程管理、数据转换、应用接口、中间消息服务和系统连接传输这六个整合层次的集成，并附以信息安全管理和系统管理及监控方可达成真正的企业集成。其中外部协作层和业务流程管理层属于业务层面，数据转换层和应用适配层属于接口层面，中间消息服务层和系统连接层属于中间件层面：

EAI的六个整合层次分别为：

层次1：外部协作层（Collaboration Layer）

层次2：业务流程管理员（Process Layer）

层次3：数据转换层（Transformation Layer）

层次4：应用适配层（Adapter Layer）

层次5：中间消息服务层（Messaging Layer）

层次6：传输层（Transport Layer）

下面就企业应用集成（EAI）在银行业的应用进行讨论并用概念验证（POC）的实施方法对EAI在商业银行的实现作一初步探讨。

2 EAI应用集成模式在银行业的应用

EAI本质上是通过对应用功能的集成，实现企业业务流程的统一化和自动化。因此，随着银行应用的发展，EAI也以不同的形式起着不同的作用。

在基础建设阶段，各应用基本采用各自独立的技术手段实现应用系统内部的信息集成。如第一代（文档电子化）和第二代（群件）办公自动化系统，以及企业资源建设（财务管理、人力资源管理）系统等。系统之间的整合较少，一般通过点对点的方式集成。

在数据大集中阶段，核心业务系统、相关前置系统、统一客户服务平台、渠道整合理念相继出现。EAI是使这些理念得以实现的核心技术，同时它又能保证架构的灵活性和可扩展性，适应业务的不断变革和发展。

在数据仓库和数据挖掘阶段，EAI是重要的使能技术。客户信息的统一视图、风险管理业务流程集成、知识发现和金融智能都需要对银行业务数据和经营管理信息的高度集成和高效流转。

2．1 面向银行业应用集成的EAI架构

2．1．1 银行业应用集成的EAI总线架构

银行EAI的总线架构包括EAI远景目标、企业集成方案和EAI概念模型：

（1）面向银行业应用集成EAI的远景目标

EAI建设是改善银行整体信息技术能力的战略性项目，而且EAI架构的改进是一个长期的不断变化的过程。要使整体的EAI建设符合银行整体发展的要求，并指导未来长期的EAI建设过程，首先需要确立银行的EAI远景目标。

银行的EAI远景目标包括远景、使命和目标三个层次。其中，远景（Vision）是银行企业应用集成的总体目标，即：利用企业应用集成及中间件技术，用于集成全行应用系统的统一平台。即：实现业务流程标准化和自动化，统一银行应用系统的技术标准，实现系统间信息共享、资源互通、数据同步，实现新产品的快速上线，新系统的快速开发和部署，降低实施和运作成本，实现渠道整合，满足多样化需求，提供一站式服务，实现统一的安全机制，以实现应用系统的整合，保证应用体系架构的灵活性、可扩展性。目标（Goal）是银行企业应用集成的战术性目标，即：实现集成的核心业务系统和提供客户信息的统一视图等。 制订清晰的银行EAI总体目标、战略目标和战术目标，对于制订银行EAI的蓝图建设具有直接的指导意义。

（2）面向银行的企业应用集成方案

在确立了银行的EAI远景目标后，将进一步确立银行的企业集成解决方案。

银行的企业集成解决方案必须从银行的整体业务战略出发，而且要符合银行IT战略的要求。银行的EAI（企业集成）解决方案可以划分为EAI集成方案和EAI管理方案两大部分。其中，EAI集成方案指导银行EAI的技术方面的建设，可以划分为：原有系统集成方案，未来系统集成方案，外部集成方案。原有的系统集成方案阐述银行原肖系统集成的目标和方针；未来系统集成方案给出集成银行的未来应用的指导原则；外部集成解决方案指导银行与外部合作伙伴、客户的集成活动。

EAI管理解决方案指导银行EAI的架构和管理方面的工作，可以划分为：EAI架构方案和EAI管理方案。EAI架构方案给出EAI架构建设和维护的解决方案指导；EAI管理方案阐述银行EAI建设和维护的组织结构，EAI管理和维护的战略性方向。

（3）面向银行业EAI的概念模型

EAI的概念模型是对EAI的模块分解和功能定义，EAI要领模型如图1所示。

2．1．2 面向银行业应用集成的EAI目标架构

EAI目标架构是指在EAI总体架构指导下所推导出的包括具体技术功能描述的EAI逻辑视图。建立EAI系统的最重要的目的是建立银行的统一的集成架构，满足银银行的完整集成的要求。建立这些架构的总体原则是在借鉴国际银行相关架构的最佳实践的基础上，结合银行的当前业务和技术架构的现状，以及银行的业务和技术架构发展的战略和需求，综合确定EAI的架构。

银行的EAI架构包括业务集成架构、应用组合架构和技术集成架构。

业务集成架构主要描述银行的各项主要业务之间的逻辑关系、交互过程、以及共享流程的架构。应用组合架构是业务集成架构在银行的应用和数据系统之间的关系的体现，描述了银行的主要系统之间的集成关系。技术体系架构是描述为了支持应用组合架构，需要采用的技术方案和手段，以及技术方案之间的联系。而EAI治理架构是支持EAI的整体建设和维护工作，所需的组织结构的保证以及相关的资源组织方式和管理模式。由于银行EAI的建设是一个长期的过程，并且由于业务和技术的发展，EAI的整体集成架构和方式处于持续的变化过程中，因此维护和处理EAI相应变化的组织和治理模式，是银行IT治理模式的一个重要组成部分。

为了EAI的建设真正符合业务发展的要求，需要首先根据银行的业务经营和管理功能的现状和需求，确定银行的业务集成架构。然后再结合银行的应用集成现状、未来的IT架构，确定银行EAI的应用组合架构。在确定了应用组合架以后，开始评估能够实现银行应用组合架构所需的各类技术方案，从而建立银行EAI的技术体系架构。而在建立EAI技术体系结构的同时，需要根据银行的现有集成开发和管理能力，以及未来EAI发展的要求，确定银行EAI的管理组织架构。所有这些架构的分析和建立过程，都必须参照国际银行的最佳实践，再根据银行的现有情况进行定制。

2．2 面向银行业应用集成EAI的初步实施策略-POC（概念验证）

2．2．1 POC的目的

根据以往EAI项目的实施经验，从一个有限范围的概念验证开始着手是最快的。因此POC是项目实施方法的一个重要阶段，它将针对前面论述的商业银行EAI目标架构，选择典型的目标架构所欲实现的功能，通过对有代表性的案例和场景进行模拟，进而对模拟结果进行量化分析，以确定各目标架构方案的可行性和有效性。同时，POC还可以明确在EAI实施过程中可能出现的主要风险和问题，并确认关键成功因素和所需的资源等。图3 由于商业银行的EAI目标架构在一个至多个EAI平台上针对不同的业务目标分别实现了不同的功能，通过完成一个完整的POC过程，能够确定通过实现EAI的不同特性所设计的多个目标架构，在同一平台上是否能够协同工作并产生最优化的平台性能。

2．2．2 POC的方法

根据以往的EAI实施经验，一般采取以下的步骤帮助客户完成POC的工作：

1．针对已经规划完毕的EAI的架构和功能，与客户讨论并确定POC的范围和内容。

2．根据上述范围和内容所包含的需求，选择典型的案例和场景，与客户讨论并设计不同的分析流程和量化指标。

3．建立初步系统模型，模拟场景和案例，提取、转换、加载样本数据，以测试系统的功能。

4将模型安装与客户处，以验证可行性。

5．根据POC的结果，调整目标架构并指导产品选型。

2．2．3 POC的范围和内容

根据为商业银行所做的业务需求分析以及EAI目标架构可知，各部分业务目标所需解决的业务问题主要分为数据同步，跨系统实时交易，规则引擎，交易路由，B2Bi以及多个EAI平台的互连等几大类。这几大类功能本身均是基于EAI技术的一个或者多个特性来实现的。因此，适当的从这几大类功能中选取部分并根据业务需求实现验证目标，从而覆盖EAI的各个技术特点，即能够验证EAI的各种特性在实现以上功能时的可行性和有效性。

根据EAI目标架构中对不同目标架构的技术分析可知，不同目标架构中需要EAI实现的功能和EAI自身的技术要点关系如表1。表1

根据表1的对应关系，结合目标架构中近、中、远期的总体目标架构演进策略可以看出，从客户信息、OCRM以及分行企业应用整合系统三个目标架构中的业务目标作为POC的范围，从其业务需求中适当选取部分组成典型案例和场景作为POC的内容，即能够覆盖所有当前EAI的特性。具体PCO的内容应从目标架构所设计的具体业务需求中选取，在选取的过程中应当遵循以下原则：

1．具有典型性和普适性；

2．测试数据可以被获得；

3．需求通过相对简单的开发即能够被完成；

4．验证结果可以被量化。

2．2．4 POC场景选择

根据分析，可以从客户信息、OCRM以及分行企业应用整合系统三个目标架构中的业务目标作为POC的范围，从其业务需求中适当选取部分组成典型案例和场景作为POC的内容，以验证以下EAI技术特性：

·可用性和可扩展性

·系统集成能力

·数据结构、行业标准的支持

·开发工具集成/支持

·BPM引擎功能

·B2B集成功能

·安全和事务处理

POC场景：通过网银代交水电费

场景描述：

用户通过网上银行查询、交纳水电费。涉及系统包括网银、外联单位系统、代收费系统（中间业务平台）和客户信息，如图2所示。

验证要点：

1．工作流引擎（BPM）：对交费自动化流程及人工参与流程（根据角色与任务）、流程监控以及可视化的流程建模工具等的支持、对工作流规范的支持、流程内事务控制、流程异常处理和流程运行效率。

2．B2Bi：实现中间业务平台与外部单位的B2B接口，这里通过Webservice方式查询、处理交费信息；交费信息通过SMS GW发到客户手机上；考察对B2B的支持能力，是否提供相应的B2B产品或产品模块；对B2B数据标准的支持，如ebXML,RosettaNet，EDI等。

3.其他技术要点包括适配器、数据转换、错误处理和日志管理。

场景分析（如图3所示）：

1．客户登陆网银；

2．客户查询水电费；

3．网银系统将查询信息通过EAI发送到代收费系统；

4．代收费系统通过EAI将查询信息发WebService的方式请求外联单位系统；

5．外联单位通过EAI将查询结果反馈给客户；

6．客户发起交费请求；

7．代收费将交费请求通过EAI发送给大前置（核心银行数据中心主机）；

8．代收费系统接收大前置（核心银行数据中心主机）的交费结果信息；

9．交费成功后，代收费系统通过EAI将交费信息以异步方式更新客户信息；

10．交费成功后，代收费系统通过EAI以异步方式向SMS GW发送交费成功信息。

本文介绍了EAI业务应用集成的基本概念、四种集成形式和六个整合层次；论述了面向银行业的总体架构和目标架构并对面向银行业的EAI的初步实施策略-POC（概念验证）进行了实步探讨。希望本文能对从事于金融电子化方面或对其感兴趣的读者能有一点益处。