EAI项目实施经验谈

作者：

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 引言 企业信息化是个永无止尽的话题，不同的发展时期，不同的商业环境，都迫使企业信息系统不断发展变革，以适应 “随需应变”的商业环境，保持旺盛的企业竞争力。国内企业，在经历了若干年的基础信息系统建设和发展之后，已进入了功能应用系统相对成熟完善的平台期，而如何在既有体系下提升企业系统的协作与应变能力，优化业务流程和管理体系，降低业务成本与系统风险，最大化地挖掘数据价值，成为了这一时期发掘企业竞争力的技术热点。通常将在企业内部各自为政的独立功能系统间建立应用集成、事务协作与流程自动化体系称为EAI，而在全球范围内的企业与企业之间的信息数据交换与电子商务交易，被称为B2Bi。EAI是以面向Intranet为主，而B2Bi则以面向Internet为主，而两者所采取的集成技术也不尽相同，比如EAI,可以采用非XML Web Services架构去实现，而B2Bi因为“标准化”的需要，更多的是通过Web Service来实现的。(而本质上，两者的都是以减小耦合，增强协作为目的。本文将综合EAI和B2Bi两个概念的共性，统称为EAI展开描述) 。EAI是较为特殊的企业信息化项目，通常的企业信息化项目是面向企业的应用领域的功能系统，而EAI事实上并不面向企业应用的特定功能需求，而是在多个功能系统的基础上提供一套连接和协调整个应用体系和企业价值链的信息系统协作解决方案。本文将围绕EAI的项目实施过程，与大家分享笔者在EAI技术项目中的一些经验与心得。 十面埋伏 正是由于EAI技术领域的着眼点和问题域的特殊性，与传统应用系统的建立实施项目相比，EAI项目在实施中也突显出了诸多差异，这些特点有些体现为项目中所必须直面的困难，有些则是项目问题的经验教训总结，在此将这五大困扰一一道来： １．参与角色不定性 通常的企业信息化项目的参与角色无外乎有两大类，提出应用需求的最终客户和应用解决方案提供商，而EAI项目可能会有企业最终用户、为企业提供旧有应用系统的多个厂商、为最终客户提供连接原有多个应用系统实现跨系统解决方案的应用集成商三种角色。不难看出，EAI技术实施项目的参与角色比传统应用系统的应用需求企业和解决方案供应商更为复杂，而且在这三种角色之间，仍然有角色的重叠与转化。如，在较为简单的情况下，为最终客户提供EAI解决方案的厂商就是原有应用系统的供应商，而如果应用系统是由最终客户自主开发，那么三者的角色就完全重叠。但更多的实际情况则更为复杂，如：一个或多个最终客户（如果是企业内集成为一个，如果是企业间集成为多个），一个或多个应用厂商（对接的若干应用系统可能来自于一到多个应用开发商），一个或多个EAI厂商（整个EAI项目可能由一家应用集成商独立承担，或由多家分别负责不同应用改造的厂商协作完成）。 ２．合同关系复杂性 正因为EAI项目的角色不定性所决定，EAI项目的合同关系突显出了更大的复杂性，一些合同是由于应用厂商希望为自身的应用系统提供标准化规范化的接口而主动向最终客户提出整改需求的，另外的情况是最终客户意识到或迫切需要EAI技术来连接企业价值链中的多个应用系统而提出需求。在合同的订立上，存在最终客户与应用厂商、应用厂商与EAI厂商、最终客户与EAI厂商等多种可能。而应用厂商中，又有应用集成的主动发起方和集成的被动的配合应用厂商。在权利和义务的界定上较为复杂和困难，如果合同订立不够严谨慎密，极易导致项目实施中协调困难或相互扯皮，项目难以继续开展。这也是笔者在早期的几个项目中的前车之鉴，合同关系的脉络梳理不得法，将导致在法律地位和谈判角度上始终落于下风，不利于后续工作的开展。 ３．客户需求差异性 正如企业应用系统的需求差异性导致产品化的企业应用系统可行性极低一样，连接复杂多变企业信息系统的EAI项目同样存在着差异性和复杂度风险，试图提供或实现完全产品化的EAI解决方案根本就是不切实际的空中楼阁。这里指满足企业客户最终业务需求的完整方案，产品化的EAI服务器只能满足某种程度的抽象需求，而EAI的实施厂商必须在此基础上进行大量的定制开发与配置部署工作，这样方可满足不同的应用集成需求和适应差异性体系环境，从而完成最终项目。在企业内部的EAI项目，多数是进行流程运转、事务协作、财务统计、业务处理、企业内部策略等管理体系下的信息交互与应用集成；而在企业与企业之间的B2Bi当中，更多的是进行上下游的供应链厂商之间采购供应、财物流转、电子贸易、行业内的统计监督审核与信息发布等等，而事实上在项目实施中即使是同样的业务需求，不同的应用系统，不同的业务流程也会导致需求的差异变化。举例来说，在企业内部一个跨系统的财务审批流程，不同的企业就会有不同的理解和管理制度，这也正是EAI开发商和实施者不容忽视客现差异。 ４．技术手段多样性 EAI项目的技术实现手段较为灵活，通过消息通讯（如Socket直连、消息队列）、数据交换（如EDI、数据中间表）、应用组件（如DCOM、EJB）等多种技术手段都可满足分散系统在数据、应用、商业逻辑及用户界面等多个层面的集成交互的不同需求。而这些技术又可按其交互模式分为同步实时和异步非实时两大类技术。而从对应用系统的影响角度看，实施技术方案又有对应用系统完全透明的非侵入式集成和需要改造应用系统适应EAI接口需求的侵入式集成。不同的应用厂商和最终客户也会对操作系统、数据库系统、开发语言与应用环境等系统平台和实现方案有历史的积累或特别的偏爱。在项目过程中，项目决策者与架构设计人员面临着从多层次多元化的技术手段中甄选适合自身项目的一种或多种集成技术的难题。EAI厂商所提供的技术方案，应该是可以覆盖不同集成层面的整体解决方案。 ５．风险不确定性 是不是有了完善的合同保障、明晰的客户需求、全面的设计架构与成熟的实现技术，是否就可认为集成项目的成功已经唾手可得了呢？事实上并非如此，由于应用集成项目固有的复杂性，我们很快就会发现，本应按部就班的设计开发与测试验收等阶段，都无奈地遵循着“帕金森定律（Parkinson’s Law）”：项目进度不断调整，不断延期，项目“黑洞”让企业饱受人力时间成本的 “不可承受之痛”，工程实施人员“陷入”难以抽身永无宁日的“无间地狱”，这难道真的是软件工程特别是应用集成项目无法跳脱的轮回宿命吗？(君不见连以三架马车称霸世界的软件帝国Microsoft的一个Windows XP SP2都让人望眼欲穿，Longhorn的推出更是一再Delay到遥遥无期)事实上，这也是正是国内的商业应用和应用集成厂商所面临着的生存现状，也是我辈中人所不断反思与审视着的客观难题。而集成企业信息化的有机体－ERP不足10%的实施成功率更是无情地揭示了集成的困苦与前行的漩涡。难怪纵横驰骋中国IT几十年而风雨不惊的柳前辈都感慨：“上ERP找死，不上ERP等死”。信息协作有机体建立的困局不言而喻。 运筹帷幄 针对以上归纳的EAI项目五大难题，经过思考与实践，笔者也在EAI项目实施中总结了一些心得体会，希望能为关注和涉足应用集成领域的朋友提供些许参考的裨益： １．明确扮演角色，打破沟通壁垒 整合项目实施的参与者包括最终用户、应用厂商和EAI厂商，整个项目过程中，三者角色的默契配合精诚协作才能保证项目的顺利进行。管理学中的苛希纳定律给我们的警示就是“在权限冲突重叠的多方领导下的工作甚至比无主状态更难于开展，工作时间和项目成本都将成倍增加”。作为EAI项目的承接商，实施者可能要面对若干个最终客户和应用厂商，多个角色之间存在利益、权限、认识、文化等多方面的冲突与认知差异在所难免。作为EAI实施方我们应当明确自身在项目中肩负着统领号召、监控管理的决定项目成败的关键作用，以建立企业的分布（区别于相互独立的“分散”系统）信息体系为目标，做好项目的沟通交流、关系协调、权限界定等信息互动工作，并明确所有参与者在项目中的权限与义务。如果集成者受雇于其中某一应用厂商而不是最终用户，更应当注意不应事事听命于合同客户，而是直接与最终客户沟通交流，掌握一手的用户需求与全局的技术信息。 ２．完善合同细节，规避项目风险 多数的IT技术项目合同都是市场商务人员签署的，他们往往对需求差异与技术细节视而不见或漠然无知，他们往往为了自身绩效收益的一己之利，将最终客户、技术人员及整个公司推向危险与难堪的境地。多数合同都是由他们在经过了粗浅的可行性论证（甚至完全是经验主义，不进行技术评估，信誓旦旦地做出承诺拿到合同便万事大吉），在修改形式化的合同模版后订立的，极少会涉及多变的客户需求和技术协作厂商之间的技术定义。这就给未来项目的成功实施埋下了极大的隐患。由于EAI项目的特殊性，各方的技术人员应主动参与到合同的制定过程中来，进行必要的技术评估与责任分工。项目合同中的多方权利义务、合作方式、违约责任期限及终止等环节都应更多地定义和体现技术层面的内容，否则接口一方的微小变化都会导致整个项目的多个参与方测试、维护的人力时间等成本飙升，甚至因个别参与方的进度和质量导致项目无限期拖延甚至彻底失败。笔者本人的项目就有因为这样的原因而被苦苦拖累抽身不得的例子。 ３．枚举多变需求，审视旧有流程 软件业人人皆知“客户的需求一直在变”这个痛苦的真理，是故“以不变应万变”成为了软件设计者的追求（尽管达到这一目标根本不现实，只能尽可能地接近这一目标）。而在具体的的项目实施中，需求应当可以被表现描述为具体的、可枚举的、在可控范围内的分支流程变化，这样才能保证项目的如期交付和成本预算不会超支（正如拍一部电影必然需要有一个好的剧本做蓝图一样，否则项目恐怕到２０４６年也未必能完成了）。总之，客户需求所涵盖的集成功能、接口协定、业务流程等都是越早确定越好,笔者认为EAI项目的整体需求与应用环境在合同尚未签署之前，就应当基本明确。需求分析阶段只是对已枚举需求的深入与细化，而不是才开始讨论几个厂商几个系统间的接口定义。另外由于人类固有的惯性思维特质，在集成界面、业务流程方面，都应有“破旧立新”的革命性思想，因为智能化自动化的信息系统交互，并不是旧有手工业务处理与操作流程的电子化重现，而应以批判和革新的态度审视旧有的功能与流程，建立合理的、优化的、符合现代化企业管理与信息化特点的新规范与应用模式。企业应用集成商必须把握和平衡多变的商业需求、体系架构、通讯机制、系统平台、数据格式、业务流程等多个环节，才能剥丝抽茧地归纳出EAI项目的主体目标，以量化和评估项目风险、项目周期、人力与经费成本等事关项目成功与否的关键因素。 ４．甄选集成方式，坚守技术立场 以笔者的经验来看，现阶段，国内的企业信息化项目中，系统间的数据交换绝对多数都只采用了两种方式，即数据库互相开放读写（主要用于局域网或专网环境）和报文文件交换（主要用于跨网络上公网的交换，Flat File、EDI和XML都在此列），而数据库直连导致的紧耦合和访问安全问题，报文交换的实时性差和数据安全问题表明，企业信息交换的重任不应只由一两种技术手段来支撑。纵观EAI的实现技术层面，从消息通讯到应用组件自下而上具有交互能力提升，集成灵活性下降的特点。EAI接口耦合度会随交互能力的增强而大大提高，影响接口的异构集成能力；而如果追求接口的低耦合性和强集成能力，又不得不牺牲交互能力与易开发部署的能力，需要较多的工作量；侵入式集成可能改造实施难度会比较低，但改动旧有应用系统必须有应用系统厂商的支持，而且加大了兼容性稳定性等方面的风险，而为旧有应用系统建立透明适配器的非侵入性集成的实现相对要更困难，实时性较差。事实上最终用户并不会过多地关心应用集成项目所采用的细节技术，只要能满足其业务需求就可以了，但在多个实现层面中选用合适的实现技术，将对应用集成项目的实施起到事半功倍的意义。在与不同厂商的配合过程中，总会遇到同一技术问题的不同解决方案，应该本着谦虚的态度多听多学多对比，多想一些“他们的系统为什么要这样设计？”；另一方面，每个系统设计者都难以跳脱“以自身系统的角度看待一个技术问题”这样一种本位主义桎梏，总是考虑“怎样的设计才能使我们的系统改动更少？”，对于应用集成的接口项目，这将形成基于对各自系统的保护而对同一技术处理产生截然不同的抵触对立观点和解决方法，此时我们应该有理有节地坚持EAI项目主导者的立场，从整个EAI项目的架构与实施的高度来分析和应对现实问题。 ５．掌控项目要素，确保实施成功 尽管我们在项目之初就订立了完善的合同，明确了项目参与者的角色，但是在中国当前的文化背景与法规国情下，严谨慎密的合同未必能被真正严谨慎密地履行。需求在项目的设计、开发、测试等阶段并一定会一成不变，超出项目周期也并不一定会有违约金赔付；参与者也未必能恪守其角色所赋予的职责，但却可能越俎代庖干扰项目的管理决策，搅乱项目的进度和质量。人是社会生产活动中最为活跃的因素，在项目实施中人员的变更、功能的变更、流程的变更都来自于人本身，项目管理者所要应对的重要问题，就是练就一身“兵来将挡，水来土掩”的人际关系处理与沟通能力，并采用现代化的开发管理体系减低项目管理、人员管理等环节存在的风险。出于系统稳定性和项目周期的考虑，在整个项目实施过程中应采用“闭环负反馈”的策略来评估需求、功能、流程的变更和新增，因为接口一方的微小变更都有可能波及到其它对接系统，产生功能、性能、兼容等等不确定性隐患影响和为之牺牲的部署测试验收时间。而在测试部署阶段发现的功能不足与错误，也应评估其严重程度进行及时修正或延迟到下一个版本时再做完善。 步步为营 多数的EAI项目都会面对不同的行业与企业、不同的系统与需求，但整体来看却有其规律可循，只有了解应用集成项目的实施步骤，把握好项目实施的每一个环节，才可保证项目的最终成功。在此将应用集成项目实施的步骤总结为： 1．调研评估阶段需要首先了解掌握的信息： 应用需求 应用需求是企业在现有体系内或体系间的分散系统间期望和规划，即最终将以高度自动化方式实现的业务协作功能与分布事务处理能力。只有明晰地了解和掌握客户的业务逻辑和业务规划，才能整理出准确无误的应用需求。 业务流程 业务流程包括了系统间进行数据交换与业务协作的依存关系、互斥关系，处理相关事务的实际商业流程与业务逻辑等方面。应用需求是客户的业务目标，业务流程则是实现应用需求的途径和载体。 业务连接点 要将客户的应用需求与业务流程电子化，首先需要枚举出数据交换和应用集成的应用系统个数与特征，对其进行业务归纳分类和汇总抽象，掌握应用与应用，系统与系统的连接和交互关系，并结合业务流程明确应用边界和流程边界。 网络环境 掌握需要进行接口化改造的应用系统所在的下层网络环境，包括物理分布、互动关系、网络基础结构、安全、带宽、稳定性等。 系统平台 了解各应用系统的操作系统、数据库平台、开发环境、与业务应用和集成接口软件相关的部分数据库系统结构、业务逻辑的相关算法等。 协调渠道 与最终客户、应用厂商建立畅通快速的沟通渠道，能够及时有效得到相关单位相关人员的支持与配合，获取企业的中长期信息化建设规划、应用系统厂商的系统技术资料等。 2．解决方案的确定与整体设计 电子化应用流程 根据初步了解的需求信息，参考和依据实际业务应用流程和网络拓扑结构设计规划出适合于企业应用集成的电子化应用流程，电子化的应用流程可能会提出多种方案的可选性，集成厂商应将多种选择的优劣之处说明，供决策者参考权衡。 接口映射协定 建立应用集成各方与实际业务需求相关的接口映射关系，如果是数据库集成，就是双方的数据中间表对应，如果是消息通讯，就是报文格式和通讯应答的协定，如果是组件技术，则是调用接口的规范。 基础设施需求 明确满足实际业务需求与应用集成需求的相关的硬件平台、网络架构、操作系统、数据库、安全保障等平台方案的需求确立与实施规划。这些需求是支撑应用集成项目实施开展的基本前提，应确保其可按期保质保量地提供集成实施者，以免影响项目的下一步工作开展。 整体方案 确定应用集成的业务内容与电子流程、对应的技术平台、网络结构与通讯模式、根据与业务应用系统的不同集成方式确定相关的技术细节，提出完整的技术解决方案。 项目掌控 根据最终的整体方案，评估项目直接成本、间接成本、人员配备与工作量、项目周期等等，确定项目整体成本、项目工作日与项目人数、测试验收计划和标准、项目后期维护方案等。 3．项目技术实施 系统设计 绝大多数的分析工作和项目的初步设计工作在解决方案的确定过程就应该完成，在实施过程的初期应当就最终确定的解决方案进行更为详细的设计工作，结合现阶段产品的特点完成数据结构层、业务逻辑层、用户接口层的设计工作，这部分工作与项目质量密切关联，在整个项目实施过程是比较重要的环节。由于合同已经签署而真正的开发工作尚未开始，如客户在此阶段提出需求的变更和增加，应根据对系统改动影响的评估结果决定是否接受变更。 系统开发与测试 根据前期对业务需求的深入理解和项目分析设计的成果进行系统开发；原则上应按计划同步开展实验室测试，并不断根据测试结果修正错误，将系统稳定化。由于此阶段已进行实质性系统建制环境，原则上不再接受客户的变更需求，否则项目的工期与最终系统的稳定性将可能受到影响。如必须修改，则应由更改提出单位签署书面证明，说明更改的原因，造成的影响，相关的责任等。 系统上线部署 系统经过了开发与实验室测试阶段，即可进行实地部署。在上线部署过程中使用真实的业务流程和业务数据、硬件、软件和网络环境，渐进式地对功能、性能、稳定性进行测试，稳定为成熟的正式系统；由于“客户至上”的惯例，实际上在此环节中，仍可能有客户变更需求的提出，实施者应当结合商务和技术综合评估，予以应对。 4. 项目验收 系统成功实施后，应依据项目合约中的验收标准，并结合项目实施中的变更权责来完成项目的验收工作，在经过一段时间的手工/自动化业务与流程并行考验后，交付最终用户正式使用，进行EAI项目的生产应用和维护周期。 总结 软件工程不同于建筑学上的工程，后者为客户提供可高度具体化感性化认识与观测的建筑体系，而软件工程为客户提供高度抽象的难以全面感性认识的“无形无象”的软件体系。应用系统至少还有用户界面可以给用户一种表现层的感性认识，而应用集成项目就更加难以感知，因为整个项目可能除运行监控、系统日志之外，整个项目的核心系统都是没有用户界面的后台服务或中间件引擎，但却担当着连接企业信息孤岛形成企业价值链体系的会话协调与交互同步等重要任务。所以只有在项目的需求定义、分析设计、开发测试、验收运行等各个环节把握好管理、技术、资源、应用、业务、流程等多方要素才能正确地用抽象化的技术描述展现形象化的业务实体，成功建立这一高复杂度的分布式集成应用体系。本文主旨并非传递和共享通用的项目的管理经验，而是希望将作者近年来在应用集成领域项目实施过程中的些许有代表性的问题与特点做一个总结与回顾，供大家抛砖引玉时参考之用。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (11/6/2004)