出處：中國論壇網
作者：不詳
引言
企業信息化是個永無止盡的話題，不同的發展時期，不同的商業環境，都迫使企業信息系統不斷髮展變革，以適應 “隨需應變”的商業環境，保持旺盛的企業競爭力。國內企業，在經歷了若干年的基礎信息系統建設和發展之後，已進入了功能應用系統相對成熟完善的平臺期，而如何在既有體系下提升企業系統的協作與應變能力，優化業務流程和管理體系，降低業務成本與系統風險，最大化地挖掘數據價值，成爲了這一時期發掘企業競爭力的技術熱點。通常將在企業內部各自爲政的獨立功能系統間建立應用集成、事務協作與流程自動化體系稱爲EAI，而在全球範圍內的企業與企業之間的信息數據交換與電子商務交易，被稱爲B2Bi。EAI是以面向Intranet爲主，而B2Bi則以面向Internet爲主，而兩者所採取的集成技術也不盡相同，比如EAI,可以採用非XML Web Services架構去實現，而B2Bi因爲“標準化”的需要，更多的是通過Web Service來實現的。(而本質上，兩者的都是以減小耦合，增強協作爲目的。本文將綜合EAI和B2Bi兩個概念的共性，統稱爲EAI展開描述) 。EAI是較爲特殊的企業信息化項目，通常的企業信息化項目是面向企業的應用領域的功能系統，而EAI事實上並不面向企業應用的特定功能需求，而是在多個功能系統的基礎上提供一套連接和協調整個應用體系和企業價值鏈的信息系統協作解決方案。本文將圍繞EAI的項目實施過程，與大家分享筆者在EAI技術項目中的一些經驗與心得。
十面埋伏
正是由於EAI技術領域的着眼點和問題域的特殊性，與傳統應用系統的建立實施項目相比，EAI項目在實施中也突顯出了諸多差異，這些特點有些體現爲項目中所必須直面的困難，有些則是項目問題的經驗教訓總結，在此將這五大困擾一一道來：
１．參與角色不定性
通常的企業信息化項目的參與角色無外乎有兩大類，提出應用需求的最終客戶和應用解決方案提供商，而EAI項目可能會有企業最終用戶、爲企業提供舊有應用系統的多個廠商、爲最終客戶提供連接原有多個應用系統實現跨系統解決方案的應用集成商三種角色。不難看出，EAI技術實施項目的參與角色比傳統應用系統的應用需求企業和解決方案供應商更爲複雜，而且在這三種角色之間，仍然有角色的重疊與轉化。如，在較爲簡單的情況下，爲最終客戶提供EAI解決方案的廠商就是原有應用系統的供應商，而如果應用系統是由最終客戶自主開發，那麼三者的角色就完全重疊。但更多的實際情況則更爲複雜，如：一個或多個最終客戶（如果是企業內集成爲一個，如果是企業間集成爲多個），一個或多個應用廠商（對接的若干應用系統可能來自於一到多個應用開發商），一個或多個EAI廠商（整個EAI項目可能由一家應用集成商獨立承擔，或由多家分別負責不同應用改造的廠商協作完成）。
２．合同關係複雜性
正因爲EAI項目的角色不定性所決定，EAI項目的合同關係突顯出了更大的複雜性，一些合同是由於應用廠商希望爲自身的應用系統提供標準化規範化的接口而主動向最終客戶提出整改需求的，另外的情況是最終客戶意識到或迫切需要EAI技術來連接企業價值鏈中的多個應用系統而提出需求。在合同的訂立上，存在最終客戶與應用廠商、應用廠商與EAI廠商、最終客戶與EAI廠商等多種可能。而應用廠商中，又有應用集成的主動發起方和集成的被動的配合應用廠商。在權利和義務的界定上較爲複雜和困難，如果合同訂立不夠嚴謹慎密，極易導致項目實施中協調困難或相互扯皮，項目難以繼續開展。這也是筆者在早期的幾個項目中的前車之鑑，合同關係的脈絡梳理不得法，將導致在法律地位和談判角度上始終落於下風，不利於後續工作的開展。
３．客戶需求差異性
正如企業應用系統的需求差異性導致產品化的企業應用系統可行性極低一樣，連接複雜多變企業信息系統的EAI項目同樣存在着差異性和複雜度風險，試圖提供或實現完全產品化的EAI解決方案根本就是不切實際的空中樓閣。這裏指滿足企業客戶最終業務需求的完整方案，產品化的EAI服務器只能滿足某種程度的抽象需求，而EAI的實施廠商必須在此基礎上進行大量的定製開發與配置部署工作，這樣方可滿足不同的應用集成需求和適應差異性體系環境，從而完成最終項目。在企業內部的EAI項目，多數是進行流程運轉、事務協作、財務統計、業務處理、企業內部策略等管理體系下的信息交互與應用集成；而在企業與企業之間的B2Bi當中，更多的是進行上下游的供應鏈廠商之間採購供應、財物流轉、電子貿易、行業內的統計監督審覈與信息發佈等等，而事實上在項目實施中即使是同樣的業務需求，不同的應用系統，不同的業務流程也會導致需求的差異變化。舉例來說，在企業內部一個跨系統的財務審批流程，不同的企業就會有不同的理解和管理制度，這也正是EAI開發商和實施者不容忽視客現差異。
４．技術手段多樣性
EAI項目的技術實現手段較爲靈活，通過消息通訊（如Socket直連、消息隊列）、數據交換（如EDI、數據中間表）、應用組件（如DCOM、EJB）等多種技術手段都可滿足分散系統在數據、應用、商業邏輯及用戶界面等多個層面的集成交互的不同需求。而這些技術又可按其交互模式分爲同步實時和異步非實時兩大類技術。而從對應用系統的影響角度看，實施技術方案又有對應用系統完全透明的非侵入式集成和需要改造應用系統適應EAI接口需求的侵入式集成。不同的應用廠商和最終客戶也會對操作系統、數據庫系統、開發語言與應用環境等系統平臺和實現方案有歷史的積累或特別的偏愛。在項目過程中，項目決策者與架構設計人員面臨着從多層次多元化的技術手段中甄選適合自身項目的一種或多種集成技術的難題。EAI廠商所提供的技術方案，應該是可以覆蓋不同集成層面的整體解決方案。
５．風險不確定性
是不是有了完善的合同保障、明晰的客戶需求、全面的設計架構與成熟的實現技術，是否就可認爲集成項目的成功已經唾手可得了呢？事實上並非如此，由於應用集成項目固有的複雜性，我們很快就會發現，本應按部就班的設計開發與測試驗收等階段，都無奈地遵循着“帕金森定律（Parkinson’s Law）”：項目進度不斷調整，不斷延期，項目“黑洞”讓企業飽受人力時間成本的 “不可承受之痛”，工程實施人員“陷入”難以抽身永無寧日的“無間地獄”，這難道真的是軟件工程特別是應用集成項目無法跳脫的輪迴宿命嗎？(君不見連以三架馬車稱霸世界的軟件帝國Microsoft的一個Windows XP SP2都讓人望眼欲穿，Longhorn的推出更是一再Delay到遙遙無期)事實上，這也是正是國內的商業應用和應用集成廠商所面臨着的生存現狀，也是我輩中人所不斷反思與審視着的客觀難題。而集成企業信息化的有機體－ERP不足10%的實施成功率更是無情地揭示了集成的困苦與前行的漩渦。難怪縱橫馳騁中國IT幾十年而風雨不驚的柳前輩都感慨：“上ERP找死，不上ERP等死”。信息協作有機體建立的困局不言而喻。
運籌帷幄
針對以上歸納的EAI項目五大難題，經過思考與實踐，筆者也在EAI項目實施中總結了一些心得體會，希望能爲關注和涉足應用集成領域的朋友提供些許參考的裨益：
１．明確扮演角色，打破溝通壁壘
整合項目實施的參與者包括最終用戶、應用廠商和EAI廠商，整個項目過程中，三者角色的默契配合精誠協作才能保證項目的順利進行。管理學中的苛希納定律給我們的警示就是“在權限衝突重疊的多方領導下的工作甚至比無主狀態更難於開展，工作時間和項目成本都將成倍增加”。作爲EAI項目的承接商，實施者可能要面對若干個最終客戶和應用廠商，多個角色之間存在利益、權限、認識、文化等多方面的衝突與認知差異在所難免。作爲EAI實施方我們應當明確自身在項目中肩負着統領號召、監控管理的決定項目成敗的關鍵作用，以建立企業的分佈（區別於相互獨立的“分散”系統）信息體系爲目標，做好項目的溝通交流、關係協調、權限界定等信息互動工作，並明確所有參與者在項目中的權限與義務。如果集成者受僱於其中某一應用廠商而不是最終用戶，更應當注意不應事事聽命於合同客戶，而是直接與最終客戶溝通交流，掌握一手的用戶需求與全局的技術信息。
２．完善合同細節，規避項目風險
多數的IT技術項目合同都是市場商務人員簽署的，他們往往對需求差異與技術細節視而不見或漠然無知，他們往往爲了自身績效收益的一己之利，將最終客戶、技術人員及整個公司推向危險與難堪的境地。多數合同都是由他們在經過了粗淺的可行性論證（甚至完全是經驗主義，不進行技術評估，信誓旦旦地做出承諾拿到合同便萬事大吉），在修改形式化的合同模版後訂立的，極少會涉及多變的客戶需求和技術協作廠商之間的技術定義。這就給未來項目的成功實施埋下了極大的隱患。由於EAI項目的特殊性，各方的技術人員應主動參與到合同的制定過程中來，進行必要的技術評估與責任分工。項目合同中的多方權利義務、合作方式、違約責任期限及終止等環節都應更多地定義和體現技術層面的內容，否則接口一方的微小變化都會導致整個項目的多個參與方測試、維護的人力時間等成本飆升，甚至因個別參與方的進度和質量導致項目無限期拖延甚至徹底失敗。筆者本人的項目就有因爲這樣的原因而被苦苦拖累抽身不得的例子。
３．枚舉多變需求，審視舊有流程
軟件業人人皆知“客戶的需求一直在變”這個痛苦的真理，是故“以不變應萬變”成爲了軟件設計者的追求（儘管達到這一目標根本不現實，只能儘可能地接近這一目標）。而在具體的的項目實施中，需求應當可以被表現描述爲具體的、可枚舉的、在可控範圍內的分支流程變化，這樣才能保證項目的如期交付和成本預算不會超支（正如拍一部電影必然需要有一個好的劇本做藍圖一樣，否則項目恐怕到２０４６年也未必能完成了）。總之，客戶需求所涵蓋的集成功能、接口協定、業務流程等都是越早確定越好,筆者認爲EAI項目的整體需求與應用環境在合同尚未簽署之前，就應當基本明確。需求分析階段只是對已枚舉需求的深入與細化，而不是纔開始討論幾個廠商幾個系統間的接口定義。另外由於人類固有的慣性思維特質，在集成界面、業務流程方面，都應有“破舊立新”的革命性思想，因爲智能化自動化的信息系統交互，並不是舊有手工業務處理與操作流程的電子化重現，而應以批判和革新的態度審視舊有的功能與流程，建立合理的、優化的、符合現代化企業管理與信息化特點的新規範與應用模式。企業應用集成商必須把握和平衡多變的商業需求、體系架構、通訊機制、系統平臺、數據格式、業務流程等多個環節，才能剝絲抽繭地歸納出EAI項目的主體目標，以量化和評估項目風險、項目週期、人力與經費成本等事關項目成功與否的關鍵因素。
４．甄選集成方式，堅守技術立場
以筆者的經驗來看，現階段，國內的企業信息化項目中，系統間的數據交換絕對多數都只採用了兩種方式，即數據庫互相開放讀寫（主要用於局域網或專網環境）和報文文件交換（主要用於跨網絡上公網的交換，Flat File、EDI和XML都在此列），而數據庫直連導致的緊耦合和訪問安全問題，報文交換的實時性差和數據安全問題表明，企業信息交換的重任不應只由一兩種技術手段來支撐。縱觀EAI的實現技術層面，從消息通訊到應用組件自下而上具有交互能力提升，集成靈活性下降的特點。EAI接口耦合度會隨交互能力的增強而大大提高，影響接口的異構集成能力；而如果追求接口的低耦合性和強集成能力，又不得不犧牲交互能力與易開發部署的能力，需要較多的工作量；侵入式集成可能改造實施難度會比較低，但改動舊有應用系統必須有應用系統廠商的支持，而且加大了兼容性穩定性等方面的風險，而爲舊有應用系統建立透明適配器的非侵入性集成的實現相對要更困難，實時性較差。事實上最終用戶並不會過多地關心應用集成項目所採用的細節技術，只要能滿足其業務需求就可以了，但在多個實現層面中選用合適的實現技術，將對應用集成項目的實施起到事半功倍的意義。在與不同廠商的配合過程中，總會遇到同一技術問題的不同解決方案，應該本着謙虛的態度多聽多學多對比，多想一些“他們的系統爲什麼要這樣設計？”；另一方面，每個系統設計者都難以跳脫“以自身系統的角度看待一個技術問題”這樣一種本位主義桎梏，總是考慮“怎樣的設計才能使我們的系統改動更少？”，對於應用集成的接口項目，這將形成基於對各自系統的保護而對同一技術處理產生截然不同的牴觸對立觀點和解決方法，此時我們應該有理有節地堅持EAI項目主導者的立場，從整個EAI項目的架構與實施的高度來分析和應對現實問題。
５．掌控項目要素，確保實施成功
儘管我們在項目之初就訂立了完善的合同，明確了項目參與者的角色，但是在中國當前的文化背景與法規國情下，嚴謹慎密的合同未必能被真正嚴謹慎密地履行。需求在項目的設計、開發、測試等階段並一定會一成不變，超出項目週期也並不一定會有違約金賠付；參與者也未必能恪守其角色所賦予的職責，但卻可能越俎代庖干擾項目的管理決策，攪亂項目的進度和質量。人是社會生產活動中最爲活躍的因素，在項目實施中人員的變更、功能的變更、流程的變更都來自於人本身，項目管理者所要應對的重要問題，就是練就一身“兵來將擋，水來土掩”的人際關係處理與溝通能力，並採用現代化的開發管理體系減低項目管理、人員管理等環節存在的風險。出於系統穩定性和項目週期的考慮，在整個項目實施過程中應採用“閉環負反饋”的策略來評估需求、功能、流程的變更和新增，因爲接口一方的微小變更都有可能波及到其它對接系統，產生功能、性能、兼容等等不確定性隱患影響和爲之犧牲的部署測試驗收時間。而在測試部署階段發現的功能不足與錯誤，也應評估其嚴重程度進行及時修正或延遲到下一個版本時再做完善。
步步爲營
多數的EAI項目都會面對不同的行業與企業、不同的系統與需求，但整體來看卻有其規律可循，只有瞭解應用集成項目的實施步驟，把握好項目實施的每一個環節，纔可保證項目的最終成功。在此將應用集成項目實施的步驟總結爲：
1．調研評估階段需要首先了解掌握的信息：
應用需求
應用需求是企業在現有體系內或體系間的分散系統間期望和規劃，即最終將以高度自動化方式實現的業務協作功能與分佈事務處理能力。只有明晰地瞭解和掌握客戶的業務邏輯和業務規劃，才能整理出準確無誤的應用需求。
業務流程
業務流程包括了系統間進行數據交換與業務協作的依存關係、互斥關係，處理相關事務的實際商業流程與業務邏輯等方面。應用需求是客戶的業務目標，業務流程則是實現應用需求的途徑和載體。
業務連接點
要將客戶的應用需求與業務流程電子化，首先需要枚舉出數據交換和應用集成的應用系統個數與特徵，對其進行業務歸納分類和彙總抽象，掌 握應用與應用，系統與系統的連接和交互關係，並結合業務流程明確應用邊界和流程邊界。
網絡環境
掌握需要進行接口化改造的應用系統所在的下層網絡環境，包括物理分佈、互動關係、網絡基礎結構、安全、帶寬、穩定性等。
系統平臺
瞭解各應用系統的操作系統、數據庫平臺、開發環境、與業務應用和集成接口軟件相關的部分數據庫系統結構、業務邏輯的相關算法等。
協調渠道
與最終客戶、應用廠商建立暢通快速的溝通渠道，能夠及時有效得到相關單位相關人員的支持與配合，獲取企業的中長期信息化建設規劃、應用系統廠商的系統技術資料等。
2．解決方案的確定與整體設計
電子化應用流程
根據初步瞭解的需求信息，參考和依據實際業務應用流程和網絡拓撲結構設計規劃出適合於企業應用集成的電子化應用流程，電子化的應用流程可能會提出多種方案的可選性，集成廠商應將多種選擇的優劣之處說明，供決策者參考權衡。
接口映射協定
建立應用集成各方與實際業務需求相關的接口映射關係，如果是數據庫集成，就是雙方的數據中間表對應，如果是消息通訊，就是報文格式和通訊應答的協定，如果是組件技術，則是調用接口的規範。
基礎設施需求
明確滿足實際業務需求與應用集成需求的相關的硬件平臺、網絡架構、操作系統、數據庫、安全保障等平臺方案的需求確立與實施規劃。這些需求是支撐應用集成項目實施開展的基本前提，應確保其可按期保質保量地提供集成實施者，以免影響項目的下一步工作開展。
整體方案
確定應用集成的業務內容與電子流程、對應的技術平臺、網絡結構與通訊模式、根據與業務應用系統的不同集成方式確定相關的技術細節，提出完整的技術解決方案。
項目掌控
根據最終的整體方案，評估項目直接成本、間接成本、人員配備與工作量、項目週期等等，確定項目整體成本、項目工作日與項目人數、測試驗收計劃和標準、項目後期維護方案等。
3．項目技術實施
系統設計
絕大多數的分析工作和項目的初步設計工作在解決方案的確定過程就應該完成，在實施過程的初期應當就最終確定的解決方案進行更爲詳細的設計工作，結合現階段產品的特點完成數據結構層、業務邏輯層、用戶接口層的設計工作，這部分工作與項目質量密切關聯，在整個項目實施過程是比較重要的環節。由於合同已經簽署而真正的開發工作尚未開始，如客戶在此階段提出需求的變更和增加，應根據對系統改動影響的評估結果決定是否接受變更。
系統開發與測試
根據前期對業務需求的深入理解和項目分析設計的成果進行系統開發；原則上應按計劃同步開展實驗室測試，並不斷根據測試結果修正錯誤，將系統穩定化。由於此階段已進行實質性系統建制環境，原則上不再接受客戶的變更需求，否則項目的工期與最終系統的穩定性將可能受到影響。如必須修改，則應由更改提出單位簽署書面證明，說明更改的原因，造成的影響，相關的責任等。
系統上線部署
系統經過了開發與實驗室測試階段，即可進行實地部署。在上線部署過程中使用真實的業務流程和業務數據、硬件、軟件和網絡環境，漸進式地對功能、性能、穩定性進行測試，穩定爲成熟的正式系統；由於“客戶至上”的慣例，實際上在此環節中，仍可能有客戶變更需求的提出，實施者應當結合商務和技術綜合評估，予以應對。
4. 項目驗收
系統成功實施後，應依據項目合約中的驗收標準，並結合項目實施中的變更權責來完成項目的驗收工作，在經過一段時間的手工/自動化業務與流程並行考驗後，交付最終用戶正式使用，進行EAI項目的生產應用和維護週期。
總結
軟件工程不同於建築學上的工程，後者爲客戶提供可高度具體化感性化認識與觀測的建築體系，而軟件工程爲客戶提供高度抽象的難以全面感性認識的“無形無象”的軟件體系。應用系統至少還有用戶界面可以給用戶一種表現層的感性認識，而應用集成項目就更加難以感知，因爲整個項目可能除運行監控、系統日誌之外，整個項目的核心繫統都是沒有用戶界面的後臺服務或中間件引擎，但卻擔當着連接企業信息孤島形成企業價值鏈體系的會話協調與交互同步等重要任務。所以只有在項目的需求定義、分析設計、開發測試、驗收運行等各個環節把握好管理、技術、資源、應用、業務、流程等多方要素才能正確地用抽象化的技術描述展現形象化的業務實體，成功建立這一高複雜度的分佈式集成應用體系。本文主旨並非傳遞和共享通用的項目的管理經驗，而是希望將作者近年來在應用集成領域項目實施過程中的些許有代表性的問題與特點做一個總結與回顧，供大家拋磚引玉時參考之用。
