EAI项目实施经验谈.docVIP

　　EAI项目实施经验谈|第1 十面埋伏 正是由于EAI技术领域的着眼点和问题域的特殊性，与传统应用系统的建立实施项目相比，EAI项目在实施中也突显出了诸多差异，这些特点有些体现为项目中所必须直面的困难，有些则是项目问题的经验教训总结，在此将这五大困扰一一道来： １．参与角色不定性 通常的企业信息化项目的参与角色无外乎有两大类，提出应用需求的最终客户和应用解决方案提供商，而EAI项目可能会有企业最终用户、为企业提供旧有应用系统的多个厂商、为最终客户提供连接原有多个应用系统实现跨系统解决方案的应用集成商三种角色。不难看出，EAI技术实施项目的参与角色比传统应用系统的应用需求企业和解决方案供应商更为复杂，而且在这三种角色之间，仍然有角色的重叠与转化。如，在较为简单的情况下，为最终客户提供EAI解决方案的厂商就是原有应用系统的供应商，而如果应用系统是由最终客户自主开发，那么三者的角色就完全重叠。但更多的实际情况则更为复杂，如：一个或多个最终客户（如果是企业内集成为一个，如果是企业间集成为多个），一个或多个应用厂商（对接的若干应用系统可能来自于一到多个应用开发商），一个或多个EAI厂商（整个EAI项目可能由一家应用集成商独立承担，或由多家分别负责不同应用改造的厂商协作完成）。 ２．合同关系复杂性 正因为EAI项目的角色不定性所决定，EAI项目的合同关系突显出了更大的复杂性，一些合同是由于应用厂商希望为自身的应用系统提供标准化规范化的接口而主动向最终客户提出整改需求的，另外的情况是最终客户意识到或迫切需要EAI技术来连接企业价值链中的多个应用系统而提出需求。在合同的订立上，存在最终客户与应用厂商、应用厂商与EAI厂商、最终客户与EAI厂商等多种可能。而应用厂商中，又有应用集成的主动发起方和集成的被动的配合应用厂商。在权利和义务的界定上较为复杂和困难，如果合同订立不够严谨慎密，极易导致项目实施中协调困难或相互扯皮，项目难以继续开展。这也是笔者在早期的几个项目中的前车之鉴，合同关系的脉络梳理不得法，将导致在法律地位和谈判角度上始终落于下风，不利于后续工作的开展。 ３．客户需求差异性 正如企业应用系统的需求差异性导致产品化的企业应用系统可行性极低一样，连接复杂多变企业信息系统的EAI项目同样存在着差异性和复杂度风险，试图提供或实现完全产品化的EAI解决方案根本就是不切实际的空中楼阁。这里指满足企业客户最终业务需求的完整方案，产品化的EAI服务器只能满足某种程度的抽象需求，而EAI的实施厂商必须在此基础上进行大量的定制开发与配置部署工作，这样方可满足不同的应用集成需求和适应差异性体系环境，从而完成最终项目。在企业内部的EAI项目，多数是进行流程运转、事务协作、财务统计、业务处理、企业内部策略等管理体系下的信息交互与应用集成；而在企业与企业之间的B2Bi当中，更多的是进行上下游的供应链厂商之间采购供应、财物流转、电子贸易、行业内的统计监督审核与信息发布等等，而事实上在项目实施中即使是同样的业务需求，不同的应用系统，不同的业务流程也会导致需求的差异变化。举例来说，在企业内部一个跨系统的财务审批流程，不同的企业就会有不同的理解和管理制度，这也正是EAI开发商和实施者不容忽视客现差异。 ４．技术手段多样性 EAI项目的技术实现手段较为灵活，通过消息通讯（如Socket直连、消息队列）、数据交换（如EDI、数据中间表）、应用组件（如D、EJB）等多种技术手段都可满足分散系统在数据、应用、商业逻辑及用户界面等多个层面的集成交互的不同需求。而这些技术又可按其交互模式分为同步实时和异步非实时两大类技术。而从对应用系统的影响角度看，实施技术方案又有对应用系统完全透明的非侵入式集成和需要改造应用系统适应EAI接口需求的侵入式集成。不同的应用厂商和最终客户也会对操作系统、数据库系统、开发语言与应用环境等系统平台和实现方案有历史的积累或特别的偏爱。在项目过程中，项目决策者与架构设计人员面临着从多层次多元化的技术手段中甄选适合自身项目的一种或多种集成技术的难题。EAI厂商所提供的技术方案，应该是可以覆盖不同集成层面的整体解决方案。 ５．风险不确定性 是不是有了完善的合同保障、明晰的客户需求、全面的设计架构与成熟的实现技术，是否就可认为集成项目的成功已经唾手可得了呢？事实上并非如此，由于应用集成项目固有的复杂性，我们很快就会发现，本应按部就班的设计开发与测试验收等阶段，都无奈地遵循着“帕金森定律（Parkinson’s Laicrosoft的一个WindoL都在此列），而数据库直连导致的紧耦合和访问安全问题，报文交换的实时性差和数据安全问题表明，企业信息交换的重任不应只由一两种技术手段来支撑。纵观EAI的实现技术层面，从消息通讯到应用组件