經過之前幾年各大廠商對于應用整合的概念的大肆推廣、吹噓，近兩年來隨著各企業/單位的基礎系統的建設完善，應用整合類項目開始步入實質階段，而數據集成就是目前應用集成類項目中一個重要的部分，那么數據集成類的項目它的難點通常會有哪一些呢，根據自己的經驗稍微的進行了些總結，希望從事相關工作的同學們多多交流。
數據集成類的項目通常要求做到的有數據移植、數據單向交換以及數據雙向交換這三種，當然，數據交換的頻率又可分為多種情況，如實時交換、定時交換、系統閑時交換、策略觸發式的交換等，同時還有基于系統數據庫交換、中間庫的交換、標準文件的交換等幾種交換方式。
數據移植需要達到的目標是將某套系統的數據移植到另外一套系統上(通常是有相同功能的系統)，這樣的情況通常是對于原系統需停用的項目；
數據單向交換需要達到的目標是將某套系統的增量數據交換到另外一套系統中(有可能是相同功能的系統或不同功能的系統)，這樣的情況通常是對于上報類的或單向數據需求的項目；
數據雙向交換需要達到的目標是將兩套系統的增量數據互相的進行交換(有可能是相同功能的系統或不同功能的系統)，這樣的情況通常是兩套相同功能的系統并行或有雙向數據需求的項目。
對于這樣的項目各家公司在實現的過程中不會有太大的不同，有一套用于實現數據集成項目的產品，然后安排項目實施人員到現場進行數據分析，利用產品完成項目需求，在這樣的一個過程中，產品、數據分析、現場實施都是具備挺高的難度：
1、數據分析過程的難
做過數據移植的人其實都會有體會，數據分析過程是一個非常耗時費力的過程，當兩套系統都能找到原開發商的話那還好說，找不到原開發商的話做兩套系統的數據交換不亞于重新開發兩套系統的難度，在做數據分析的過程中主要是表關系的分析、表中主鍵/外鍵規則的分析以及字段的分析。
在這三者的分析上，表關系的分析相對來說還比較好做，但對于碰到有些隱性的關聯關系的表(沒有明顯的外鍵關聯)時就只能靠推測了，最慘的是碰到兩套系統采取的是完全不同的設計方法的那種，例如一方的業務系統是基于普通的業務表的設計方式的，另一方的業務系統是基于流程方式的，這樣的兩套完全不同設計的系統的表關系分析就非常的棘手了，表關系的分析上需要完成兩邊表關聯關系的分析以及兩邊系統表的對應分析(例如A系統的A表來源于B系統的A表和C表)，在做表分析的過程中非常需要系統設計較為熟練的人，對于有系統設計經驗的人而言會快和準確很多。
表中主鍵/外鍵規則的分析要做的原因是需要處理有些業務系統依靠逐漸來表達業務含義的情況，在這樣的情況下會導致交換更為的復雜，因為要處理兩邊生成規則不一致的情況，在這樣的情況下只能通過建中間表來存儲交換過程中生成的主鍵/外鍵和一方系統的對應關系，而這個地方也是數據分析過程中特別要注意的一個環節，稍不留心就可能會造成覆蓋或混亂了系統中的數據。
字段的分析上，最怕但也是會經常碰到的一種現象就是字典是帶業務含義的，這個時候如果沒有系統開發商的支持的話就會非常的麻煩了，而字段分析的過程中還有一個會非常耗時的過程就是字典的對照上，很多時候字典的對照完全靠程序難以完成，還得費人工才能完成。
可以看到，在整個的數據分析過程中，最怕碰到的就是需要交換的系統的數據庫設計中包含過多的業務含義，這個時候分析過程會變得非常的麻煩，因為通常來說數據交換廠商是不懂業務的，這個時候需要業務專家的支持才行，而且同時也可以看出，數據分析并不是一個簡單的過程，需要高級的人才才能完成，否則只能在出錯后才會發現很多的問題，而高級的人才可以在數據分析過程就避免掉很多的問題，這個非常重要，因為數據交換時才發現錯誤通常都晚了，而且后果相對來說都會比較嚴重。
上面說的主要還是基于數據庫的數據交換的方式，對于基于標準結構文件的交換方式又會稍有不同，基于標準結構文件的交換方式的最重要的問題在于標準結構的定義上，不過這個通常來說目前很多的行業都會有自己的行業系統交換標準，定義好了標準結構后，就是分析系統數據庫表結構對于文件結構的數據分析過程了。
2、實施過程的難
在實施過程中，會碰到的最大的問題還是項目協調和控制的問題，通常來說這類項目都是由集成商接下，然后數據交換廠商負責其中的數據交換的部分，這個時候呢，數據交換廠商作為專業廠商，需要控制數據交換部分的項目的進展、協調等，但往往因為是集成商接的項目，有些時候又不得不找集成商去做，這個時候會使得項目陷入一定的麻煩，另外就是和各系統開發商的協調，這個也是個比較麻煩的問題，在中國大部分的企業連跨部門的合作都非常的麻煩，何況是跨公司級別的合作呢，在客戶方面，協調也是個很大的問題，因為很多客戶對于這個領域都不了解，會想當然的認為很簡單，所以在此類項目實施時間長、難度大的問題上要有效的和客戶進行協商。
在實施的過程中，結合數據分析進行實施后會發現有些數據項無法對應的情況，這個時候呢，要和客戶進行一定的協商解決。
在雙向交換時，如果是相同功能的系統的雙向交換的話，很容易出現的現象就是數據沖突的問題，這個時候如何定制一個有效的解決方案也是難點之一。
其實從上面幾點也可以看出，做數據集成類項目的實施人員要求也是挺高的，并不像想象中的一般的產品實施人員。
3、產品的難
產品的難，難在需要有一個強大的數據轉換的設計工具，還要有一個高性能、可靠的傳輸平臺，在基于標準結構文件的數據交換項目上，高性能、可靠的傳輸平臺是非常重要的，其實基于標準結構文件的數據交換項目才能稱的上是典型的數據交換項目，基于數據庫方式的只能說是非典型的吧，:)，可以來看看一個典型的數據交換項目的數據交換過程：
● A系統產生了一條數據；
● 點擊發送可選擇發送給一個或多個的遠方系統；
● 調用設計工具中設計的轉換過程生成標準結構的文件；
● 由傳輸平臺傳送至目的系統；
● 目的系統在接受到文件后調用設計工具設計的轉換過程進行入庫或其他的操作。
在這樣一個典型的數據交換過程中，對于設計工具以及傳輸平臺都有著很高的要求，設計工具要能支持從數據庫---文件、文件---數據庫、數據庫---數據庫的轉換過程中的各種需求，做這個工具需要花費挺大的精力，而在傳輸平臺上最重要的要求就是高性能以及可靠性，高性能方面要求能夠支持高效的并發的文件的發送，可靠性方面要求文件在正常情況下的100%的到且僅到一次，在異常情況下的自動重發等策略以及異常情況下的異常原因的準確通知。
在實現定時觸發、策略觸發這些方面產品也需要花費不小的精力。
根據這些難點，可以看出，數據集成類項目其成本確實是挺高的，而且難度也不小，項目耗費的時間通常都會較長，所以做這類項目要價高其實也是正常的，但是現在多少客戶會給呢，:(