经过之前几年各大厂商对于应用整合的概念的大肆推广、吹嘘，近两年来随着各企业/单位的基础系统的建设完善，应用整合类项目开始步入实质阶段，而数据集成就是目前应用集成类项目中一个重要的部分，那么数据集成类的项目它的难点通常会有哪一些呢，根据自己的经验稍微的进行了些总结，希望从事相关工作的同学们多多交流。
数据集成类的项目通常要求做到的有数据移植、数据单向交换以及数据双向交换这三种，当然，数据交换的频率又可分为多种情况，如实时交换、定时交换、系统闲时交换、策略触发式的交换等，同时还有基于系统数据库交换、中间库的交换、标准文件的交换等几种交换方式。
数据移植需要达到的目标是将某套系统的数据移植到另外一套系统上(通常是有相同功能的系统)，这样的情况通常是对于原系统需停用的项目；
数据单向交换需要达到的目标是将某套系统的增量数据交换到另外一套系统中(有可能是相同功能的系统或不同功能的系统)，这样的情况通常是对于上报类的或单向数据需求的项目；
数据双向交换需要达到的目标是将两套系统的增量数据互相的进行交换(有可能是相同功能的系统或不同功能的系统)，这样的情况通常是两套相同功能的系统并行或有双向数据需求的项目。
对于这样的项目各家公司在实现的过程中不会有太大的不同，有一套用于实现数据集成项目的产品，然后安排项目实施人员到现场进行数据分析，利用产品完成项目需求，在这样的一个过程中，产品、数据分析、现场实施都是具备挺高的难度：
1、数据分析过程的难
做过数据移植的人其实都会有体会，数据分析过程是一个非常耗时费力的过程，当两套系统都能找到原开发商的话那还好说，找不到原开发商的话做两套系统的数据交换不亚于重新开发两套系统的难度，在做数据分析的过程中主要是表关系的分析、表中主键/外键规则的分析以及字段的分析。
在这三者的分析上，表关系的分析相对来说还比较好做，但对于碰到有些隐性的关联关系的表(没有明显的外键关联)时就只能靠推测了，最惨的是碰到两套系统采取的是完全不同的设计方法的那种，例如一方的业务系统是基于普通的业务表的设计方式的，另一方的业务系统是基于流程方式的，这样的两套完全不同设计的系统的表关系分析就非常的棘手了，表关系的分析上需要完成两边表关联关系的分析以及两边系统表的对应分析(例如A系统的A表来源于B系统的A表和C表)，在做表分析的过程中非常需要系统设计较为熟练的人，对于有系统设计经验的人而言会快和准确很多。
表中主键/外键规则的分析要做的原因是需要处理有些业务系统依靠逐渐来表达业务含义的情况，在这样的情况下会导致交换更为的复杂，因为要处理两边生成规则不一致的情况，在这样的情况下只能通过建中间表来存储交换过程中生成的主键/外键和一方系统的对应关系，而这个地方也是数据分析过程中特别要注意的一个环节，稍不留心就可能会造成覆盖或混乱了系统中的数据。
字段的分析上，最怕但也是会经常碰到的一种现象就是字典是带业务含义的，这个时候如果没有系统开发商的支持的话就会非常的麻烦了，而字段分析的过程中还有一个会非常耗时的过程就是字典的对照上，很多时候字典的对照完全靠程序难以完成，还得费人工才能完成。
可以看到，在整个的数据分析过程中，最怕碰到的就是需要交换的系统的数据库设计中包含过多的业务含义，这个时候分析过程会变得非常的麻烦，因为通常来说数据交换厂商是不懂业务的，这个时候需要业务专家的支持才行，而且同时也可以看出，数据分析并不是一个简单的过程，需要高级的人才才能完成，否则只能在出错后才会发现很多的问题，而高级的人才可以在数据分析过程就避免掉很多的问题，这个非常重要，因为数据交换时才发现错误通常都晚了，而且后果相对来说都会比较严重。
上面说的主要还是基于数据库的数据交换的方式，对于基于标准结构文件的交换方式又会稍有不同，基于标准结构文件的交换方式的最重要的问题在于标准结构的定义上，不过这个通常来说目前很多的行业都会有自己的行业系统交换标准，定义好了标准结构后，就是分析系统数据库表结构对于文件结构的数据分析过程了。
2、实施过程的难
在实施过程中，会碰到的最大的问题还是项目协调和控制的问题，通常来说这类项目都是由集成商接下，然后数据交换厂商负责其中的数据交换的部分，这个时候呢，数据交换厂商作为专业厂商，需要控制数据交换部分的项目的进展、协调等，但往往因为是集成商接的项目，有些时候又不得不找集成商去做，这个时候会使得项目陷入一定的麻烦，另外就是和各系统开发商的协调，这个也是个比较麻烦的问题，在中国大部分的企业连跨部门的合作都非常的麻烦，何况是跨公司级别的合作呢，在客户方面，协调也是个很大的问题，因为很多客户对于这个领域都不了解，会想当然的认为很简单，所以在此类项目实施时间长、难度大的问题上要有效的和客户进行协商。
在实施的过程中，结合数据分析进行实施后会发现有些数据项无法对应的情况，这个时候呢，要和客户进行一定的协商解决。
在双向交换时，如果是相同功能的系统的双向交换的话，很容易出现的现象就是数据冲突的问题，这个时候如何定制一个有效的解决方案也是难点之一。
其实从上面几点也可以看出，做数据集成类项目的实施人员要求也是挺高的，并不像想象中的一般的产品实施人员。
3、产品的难
产品的难，难在需要有一个强大的数据转换的设计工具，还要有一个高性能、可靠的传输平台，在基于标准结构文件的数据交换项目上，高性能、可靠的传输平台是非常重要的，其实基于标准结构文件的数据交换项目才能称的上是典型的数据交换项目，基于数据库方式的只能说是非典型的吧，:)，可以来看看一个典型的数据交换项目的数据交换过程：
● A系统产生了一条数据；
● 点击发送可选择发送给一个或多个的远方系统；
● 调用设计工具中设计的转换过程生成标准结构的文件；
● 由传输平台传送至目的系统；
● 目的系统在接受到文件后调用设计工具设计的转换过程进行入库或其他的操作。
在这样一个典型的数据交换过程中，对于设计工具以及传输平台都有着很高的要求，设计工具要能支持从数据库---文件、文件---数据库、数据库---数据库的转换过程中的各种需求，做这个工具需要花费挺大的精力，而在传输平台上最重要的要求就是高性能以及可靠性，高性能方面要求能够支持高效的并发的文件的发送，可靠性方面要求文件在正常情况下的100%的到且仅到一次，在异常情况下的自动重发等策略以及异常情况下的异常原因的准确通知。
在实现定时触发、策略触发这些方面产品也需要花费不小的精力。
根据这些难点，可以看出，数据集成类项目其成本确实是挺高的，而且难度也不小，项目耗费的时间通常都会较长，所以做这类项目要价高其实也是正常的，但是现在多少客户会给呢，:(