应用集成方案概述

《应用集成方案概述》由会员分享，可在线阅读，更多相关《应用集成方案概述（6页珍藏版）》请在装配图网上搜索。

1、应用集成方案概述-张旭、 一 、一前言2009 到2011的三年中我先后拜访了100多家国内企业，进行应用集成售前工作，并在 数十个项目中担任实施顾问或是实施项目经理。、这些企业中大多都同时运行着多个来自不 同软件供应商的企业应用。由于这些应用是独立部署的，他们很难获取到其他系统的信息也 无法把本系统中的信息传递到下游系统，这就导致了完整的企业流程被数个不同的应用强行 割裂。企业只能通过人工方式才能将众多业务流程连接到一起，而这种人工的方式往往是低 效和易错的。这些企业的应用集成需求大多来自企业一线或是来自客户，但是 70%以上应用项目是直 接由企业一把手或是CIO推动的。也许从企业高层领导的

2、视角看，这些独立的应用与他们所 期望的完整高效的信息系统差距还很大。摆在这些决策者的面前的似乎只有两条道路：第一，使用一个单一供应商提供的全面解 决方案。第二：通过应用集成将这些系统整合。不管周围有多少争论，我始终认为企业的应用集成工作是不可避免的。无论市面上是否 有厂商能够为企业提供一个足够大的全面应用的软件，这个应用都不可避免的会与其他应用 交互。比如上下级企业，供应链上下游的企业，社会公共平台，政府监管机构，电子商务平 台等等。尤其是很多厂商提供的一体化应用并不像他们宣称的那样灵活和适用，所以众多异 构软件在企业中并存将是一个长时间的现象。传统的应用集成方式存在诸多弊端，仅仅依靠在两个数

3、据库中传递数据或者相互之间调 用接口的模式很难解决企业的整体集成问题。无论是在理论上或是实际中，这样的集成方式 注定意味着项目的失败。当前的市场存在着众多的IT人员外包公司，众多集成软件供应商， 然而企业真正需要的是一套可行的应用集成整体解决方案。本方案是在几个原型项目中逐渐成型的。这个方案回答了当前关于如何进行应用集成的 几个关键问题，即应用集成的目标，应用集成的方法以及如何进行应用集成实施。虽然我们 的项目并不像我们所期望的那样完美，但是方案中所体现的众多价值点已经在后续的项目中 陆续显现，只要我们按照这个规划好的道路走下去，我相信完整集成只是时间的问题。概念体系为了我们能够在同一个环境中

4、讨论应用集成的问题，首先统一几个概念的定义。组织：人与人结成的团体。人们结成组织的目的是为了达到单人所无法达到的目的。同 时一个组织的效率取决于这个组织的协作能力。组织规模越大，协同能力越高那么这个组织 所能够发挥出的能量就越多。信息系统：组织中为了增强协作所建立的用于收集信息，处理信息，传递信息的体系。 所有为了这个目的所投入的人，财，物均属于信息系统范畴。比如，古代的驿站系统，烽火 戏诸侯故事中的烽火台，航海中的旗手和旗语都属于信息系统的范畴。信息技术（IT :现代科学发明的高效信息处理方法。如电话，手机，计算机，互联网，数据库，应用软件，云计算，物联网，移动应用等。信息化的定义：利用先进

5、的IT技术对传统的信息系统进行全面改造的过程。现代的信息技术为组织内的信息系统带来了剧烈的变革。信息系统在信息存储量，信息 传递数据，信息处理能力等各个方面都有了巨大的提升。同时信息系统的巨大变革也影响到 了组织的其他方面，比如组织的管理模式，生产经营模式，销售模式等。我们当前的信息化 建设手段主要是应用各种管理软件，而这种依靠管理软件来提高组织内信息体统效率的作法 在某个时候会达到瓶颈值，只有通过系统整合或者是集成的方法才能够进一步提高信息系统 的效率。应用集成目的应用集成的目的是通过“应用集成技术”将组织内的异构软件进行组合，让这些组合后的软件就好像是一套软件:“统一的界面，一份基础数据和

6、通畅的信息流”。应用集成的具体目的:1、一体化:通过将组织内现有系统和未来系统进行有机组合形成一个大的，覆盖组织内所有信息业务的信息整体；2、柔性和可扩展:建立一个框架，让这个一体化中的各个成员（异构系统）即能够独立应用又能够有机组合，甚至当这些成员进行版本升级或是替换的时候都不影响其 他应用。3、开放性：组合后的系统能够方便的和其他应用交互信息。如上下级企业应用，供应 链上下游企业，社会公共平台，政府监管机构和电子商务平台。一个明确的目标是鉴定应用集成方案优劣的重要手段。不同的目标下会选择不同的集成 方案。既然企业的整体应用集成工作不可避免，那么确定一个明确的整体目标和一套先进的 集成方法才

7、是企业在未来数年内综合受益最大化的保障。集成的方法面向服务集成在以往的应用集成项目中，由于没有统一的规划和整体的目标，很多技术牛人热衷于暴 力技术流集成。他们总是关注每个系统的底层数据结构，喜欢破解代码或是在软件的外围做 各种agent。这种方法固然能够在短时间内起到很好的应用效果，立竿见影的解决应用的问 题，但是我们认为这种基于底层结构的改造方式通常比较脆弱，软件的升级、版本变动或是 软件商替换对整体的结构都将产生灾难性的影响。面向服务的集成方法是一种抛弃了关注具体实现细节的集成方法。在SOA的框架下， 系统之间是一种契约关系，而抽象出的服务就是这种契约的体现。也就是说一旦服务被定义 了，那

8、么如何实现这个服务我们不关心，但是服务是你的承诺，无论软件升级或者改版都需 要遵守，服务是对系统的要求。而实现集成的过程也被转变成发布服务和消费服务的过程。第一步，发现服务。看这个系统“是干什么的”，他应该接收哪些上游的信息？他能够 提供哪些专业信息给别人共享？他的责任是什么，能够为别人提供什么服务？服务的粒度要 大于接口，也就是说服务的抽象程度比较高，更加概括。这个事情需要专业的架构人员来做， 而企业需要的是得到一份应用系统服务设计文档。第二步，谁来消费服务。我们会根据业务的应用场景考虑让每个系统如何消费其他系统 提供的服务。比如把信息推送到其他系统或是在业务过程中获取某些非本系统的信息用于

9、校 验或是获取其他系统的基础信息等等。这样就在服务的发布和消费过程中，完成了集成。面向服务的架构有以下的优势1、系统开放服务是一种公开的对外承诺。有了这些承诺，系统也就开放了。除了通过服务的调用，其他途径的集成都是走的密道。既然是密道，那么如果哪天密道消失了我们也怪不得别人，而最终损害的还是企业的利益。2、减少了接口传统集成是由需求引导，需要集成什么内容就开发一个什么接口，和谁集成就为谁制定一个接口。在大规模集成的过程中，这样的接口就会很多。由于没有前期的规划和抽象，很多接口的功能是类似的，或者可以合并成一个接口，或者应当拆分成几个接口。 服务本身在技术角度和接口是类似的，但是合理的服务设计可

10、以保证较少的接口数量。3、降低了耦合度系统之间一旦有了“服务”的契约，那么相互之间就解耦了。一个人负责一件事情， 出了错误就知道找谁。而且服务对于具体实现的程序也不关心，不会把两个系统的应用 场景混合在一起考虑。低耦合度的架构能够更好的适应应用的变动。我们在经过几个应用集成原型项目实施过后，总结了一套应用集成规范。虽然这套规范 覆盖的业务不多，但是这套规范在后续数个项目中都保持了良好的通用性。我们也希望这套 规范能够让更多的企业和软件供应商认可，因为这样才能发挥它最大的价值。主数据管理基础数据统一在前，业务流程集成在后。众多异构系统的业务数据交互就像是多个国家 进行贸易一样，每个国家都有自己的

11、货币，税收方式和标准语言，如果两个国家的商团进行 贸易，那么所有基础信息都要进行翻译才能完成贸易。没有做过基础数据统一的应用系统也是这样。众所周知每个应用系统大都利用数据库进 行结构化的数据存储，而在这样结构化的数据存储中一旦涉及基础数据都只存储数据的 ID 号码，这就导致了两个异构传递业务信息时，所有的基础数据都要进行翻译。比如应用于企 业的人力资源管理系统需要传递工资单到财务系统的时候，那么存储在两个系统中的人员， 单位，部门，岗位等信息都需要进行转译。这样的转移工作量是巨大的，尤其是需要进行大 量业务流程集成工作时。我们的应用集成方案中，希望能够首先统一所有系统中的基础数据，然后在基础数

12、据统 一的前提下进行业务集成。我们按照以下步骤进行基础数据统一工作。1、梳理基础数据我们定义系统间共享的数据为基础数据。如企业中的员工数据，部门机构数据，岗 位数据，物资分类数据，供应商数据，客户数据等等。2、找到基础数据的业务入口。（对应的系统及管理部门） 对于每种数据，找到它在组织中的权威入口。比如，人员数据在人力资源部门首先 录入。供应商数据在财务系统中录入（尚未使用供应商关系管理系统，如果应用了 SRM则主数据录入位置转移到SRM系统中）。3、让所有系统共享基础数据 当基础数据进入组织的某个应用的时候，所有的相关应用都能够自动的共享这些数 据，而不是依靠人工同步或是各自维护。应用效果：

13、对于每种基础数据做到只有需要唯一的一个录入地点，然后就能在所有的应 用中自动的共享。应用企业服务总线ESB ，MDM，Portal 等集成软件的应用使得我们的集成项目事半功倍。尤其是企业服务 总线（ESB ）软件的应用。很多应用集成厂商将企业服务总线当成是系统间数据的通道，因 为企业服务总线拥有强大的接口适配，数据适配，数据传输功能，并且企业服务总线可以很 方便的对传输中的数据和接口进行监控和日志记录。但是我们认为，企业服务总线最主要的 作用是让我们设计的 SOA 架构能够真正的落地。当我们的服务规范被定义出来以后，每个 系统就不再关心其他系统的存在，所有系统都只与ESB通讯。ESB总是发布着

14、能够使用的标 准服务。 ESB 就像 PC 中的主板一样，所有的工业接口标准都在主板上体现，只要符合了工 业的标准，那么CPU,内存，硬盘那样插到主板上之后就能组合一台电脑了。同样只要符合 了服务规范，所有的系统就能够迅速的通过ESB组装成一个信息整体，即使每个应用的服务 与企业标准服务有差别，利用 ESB 强大的转译功能，他也可以把这些应用变成标准的能够组 合的应用。集成的实施应用集成项目的成功，三分在设计七分在实施。应用集成项目的实施比组织中任何其他应用的实施范围都要广泛。应用集成项目的实施会牵涉到组织中的各个部门，每个软件供应 商都，这些供应商不但包括当前的供应商，未来的供应商甚至包括了

15、已经不再联系的老旧系统供应商。我们通过以下几种原则降低应用集成项目的实施难度：1、利益共享，责任共担原则虽然当前还没有一个大家都认可的计算方法，但是我们可以明确的说，整合后的应用系统比原有系统有本质提升。这样的应用集成过程不但企业受益，而且每个参与集成的软件供应商也有受益，因为他们的系统在改造的过程中由以往的封闭系统变为了开放的系统。很多我们熟知的软件并没有他们所宣称的那样开放，通过集成改造，他们的系统将变得更加开放，而且如果我们能够保证集成服务的公允性， 很多软件能够在其他项目中和另外的系统自动集成（我们就有这样现实的例子） 同时组织应当为软件厂商的集成改造适当付费。而集成设计者应当考虑现有

16、系 统的改造可行性。当然如果系统的开放性良好，已经有了自身的服务标准，那么他 的改造量就会很低。2、遵守服务规范，统一考核原则标准服务规范的制定是保障集成项目实施的关键，有了服务规范每个系统就知道了它们所应当做的工作。只要每个局部的工作都能完成，那么整体的工作也就完成了。我们还会应用服务规范对每个系统进行考核，给出集成度评价，这样就把集 成责任量化了。3、统一规划，逐步实施或暂不实施原则集成规划是必要的，它可以很好的解决我们要做哪些集成工作，如何集成的问 题。 而由于很多原因，集成的实施会受到各种阻碍，很多当前无法集成的系统（厂 商不配合，无后续服务或其他）可以暂时不集成，等到软件生命周期完成后，对于 新采购的软件进行集成要求。因为，新采购系统最容易改造和集成，其次是在实施 系统，最不容易集成的系统是老旧系统。4、设立集成厂商原则角色集成改造方案的制定会关系到每个软件厂商的具体工作量，也最容易引起争论 所以我们希望应用集成项目的实施中有独立的集成厂商角色来统一负责。5、持续集成原则应用集成工作一旦开始就将不断的持续，不但包括实施甚至连最初的设计都会不断的扩充。所以应用集成工作对于企业而言是需要长久进行的。