整合項目難做，做過的人都是很容易知道的，這也是為什么整合項目通常要規(guī)劃很久、實施很久，而且還要花費很大的財力的原因，在之前的blog中曾經(jīng)寫過整合項目難做的一些地方，像數(shù)據(jù)分析、客戶的不夠理解等。
隨著對于整合項目實施的逐步深入，碰到的難點在逐步的增多，目前手頭的一個整合項目接近完成了，對于這種類型而言的整合項目中的難點估計該出現(xiàn)的都已經(jīng)出現(xiàn)了，總結(jié)下來除了數(shù)據(jù)分析這個大難點之外，還有的難點就是業(yè)務理解的不一致、系統(tǒng)設(shè)計的不一致和協(xié)調(diào)這三個，其實業(yè)務理解的不一致和系統(tǒng)設(shè)計的不一致可以列入數(shù)據(jù)分析這個范圍，但由于這兩點對于整合項目的影響較大，會很大程度影響整合項目實現(xiàn)的難度，所以還是單獨列出來講講。
業(yè)務理解的不一致
當整合兩套業(yè)務系統(tǒng)時，對于基于服務(web服務/中間標準XML等)提供兩套系統(tǒng)的業(yè)務功能的時候還好說，因為可以根據(jù)業(yè)務的需求來制定一個統(tǒng)一的中間標準，而對于兩套系統(tǒng)通過數(shù)據(jù)庫直接連接整合的項目來說，則更為麻煩，直連庫的這種在很多的情況下都會以雙方的數(shù)據(jù)庫結(jié)構(gòu)說明書為準，這個時候在做整合時會出現(xiàn)一個很容易忽略的地方，就是兩套系統(tǒng)的設(shè)計人員對于業(yè)務理解不一致的情況，特別是兩套功能基本一致的系統(tǒng)時，這個問題會非常的突出，很明顯的一個例子就是在系統(tǒng)A中某個字段是必填項，而在另外一套系統(tǒng)中這個字段則是非必填項，有些可以通過數(shù)據(jù)庫約束來避免這種錯誤的產(chǎn)生，而有些則不行，例如在系統(tǒng)A中可能認為當字段B不為空時，字段C也不能為空，而在系統(tǒng)B中可能就不是這樣的了，這種現(xiàn)象呢，通常都只有在進入測試階段時才能發(fā)現(xiàn)這樣的錯誤，因為在數(shù)據(jù)庫結(jié)構(gòu)說明書中通常很少會有寫的這么詳細的，尤其是這種涉及業(yè)務規(guī)則的地方，更復雜的就是帶業(yè)務規(guī)則的字段，那就會更麻煩。
這樣的現(xiàn)象就會導致整合項目的周期不斷的變長，而且錯誤直到測試階段才暴露出來，再加上可能錯誤會不斷的一個接一個的逐漸的才能暴露出來，有可能會導致對于用戶的信心以及項目成員的信心造成不小的打擊。
這種情況通常在建設(shè)綜合平臺、廢除原系統(tǒng)的時候容易出現(xiàn)，因為原系統(tǒng)的這種數(shù)據(jù)庫的業(yè)務規(guī)則可能是很難了解到的，只能隨著項目的不斷進行才能逐步的暴露出來。
系統(tǒng)設(shè)計的不一致
這種現(xiàn)象對于整合項目而言是非常大的難點，這樣的難點通常都出現(xiàn)在通過數(shù)據(jù)庫直連實現(xiàn)整合的項目中，出現(xiàn)這種現(xiàn)象的時候首先是需要盡量協(xié)調(diào)其中的一家公司看看能否根據(jù)另外一家公司的設(shè)計來生成符合設(shè)計的數(shù)據(jù)，如果雙方都協(xié)調(diào)不了的話，整合廠商就只能自己來做了，這個時候就非常的復雜了，需要了解兩方的設(shè)計，然后在數(shù)據(jù)進行交換的時候來根據(jù)一方的數(shù)據(jù)來生成符合另外一方設(shè)計的數(shù)據(jù)。
這種情況對于整合廠商而言，是非常復雜的，完全不夸張的說幾乎是超出了做兩套業(yè)務系統(tǒng)的難度。
協(xié)調(diào)
廠商間的協(xié)調(diào)是整合項目中最難的地方，在整合項目中客戶是非常重要的角色，客戶能否照顧好各家廠商的利益協(xié)調(diào)好各家廠商進行配合，很大程度上決定了整合項目能否成功，如果廠商不配合的話整合項目要成功的可能性非常低，一旦協(xié)調(diào)不好很有可能會導致整合廠商成為客戶、其他系統(tǒng)開發(fā)商之間最難受的一方，也會直接導致整合項目的成功性下降，整合廠商在進行整合項目之前應該首先調(diào)查好系統(tǒng)需要涉及的開發(fā)商是否能提供配合，如有不怎么配合的開發(fā)商的話需要慎重的考慮該接口的處理。