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