分析:BPM與SOA之間的差別及聯系

關于業務流程管理(BPM)和面向服務架構(SOA)之間關系的讨論熱鬧非凡。二者也是多年來的熱門話題，但是關于它們的讨論通常都出現在互不相關的論壇上，讨論它們的人通常也屬于不同的圈子。不過現在這種情況正在改變，因為這兩個概念以及相關技術的使用者和提供者正日漸将二者結合起來看待。

　　BPM陣營通常聲稱，SOA對于實作BPM來說不是必需的。隻需部署一個BPM套件，就可以更快地實作目标而不會帶來多少複雜性。SOA陣營則注重于如何從一般意義上解決企業IT的複雜性。該陣營通常聲稱BPM是SOA的一個特性，但是它是SOA解決方案的一部分，而不是一個單獨的東西。當SOA領域的人士談到BPM時，該術語通常與服務編排或流程整合同義，而不強調對業務分析人員友好的模組化或人員互動，而後者對BPM陣營來說非常重要。

　　為了澄清這些誤解，我認為有必要闡明BPM與SOA的不同本質:SOA是一種架構方法;BPM則是一組協調活動。

　　是以，可以很容易地得到使用SOA或不使用SOA的BPM，反之亦然。我們來看看不同組合的優點。

　　如果部署一個不使用SOA的BPM套件，則可以獲得快速建立、執行和監控/管理業務流程的能力。業務流程的模型可以由業務分析人員建立，但是其完整實作則需要與底層IT系統的內建(以及定義使用者如何與該流程互動，但是現在我們暫不考慮)。BPM套件(如BEA的AquaLogic BPM Suite)支援使用各種不同的技術(面向服務的或不是面向服務的)對應用程式和資料庫進行輕松通路。實作由代碼和來自于并依賴于底層系統接口的中繼資料組成，是以，對底層資料庫和應用程式的任何更改都将導緻對業務流程的更改。

　　如果組織和IT環境規模比較小，并且由同樣一組人來控制所有的系統(包括BPM套件)的話，這是完全可以的。如果底層系統完全不更改的話，這種方法同樣運作良好。

　　但是，如果BPM套件由一個小組部署，并消費來自另一個小組的系統的服務，那麼協調和管理每個小組中的更改的任務很快就會變得非常困難。這是SOA要解決的典型問題，是以，SOA可以應用于BPM套件的部署，就像應用于其它地方一樣。

　　如果BPM作為SOA的一部分進行部署，這意味着當一個業務流程連接配接到底層系統時，它連接配接到由企業服務總線所提供的代理服務，這樣就隐藏了底層應用程式和資料庫的複雜性。這具有以下優點:

　　将業務流程連接配接到系統的過程會更簡單，因為IT可以公開更有用的接口，比如聚合的資料服務或使用标準協定而不是專有協定的服務。這減少了實作流程所需的IT工作量，并允許流程人員将精力集中于流程，而不是粘合流程與底層系統所需的技術。

　　它使得實作更為健壯，因為對底層IT系統的更改不必影響流程所使用的接口。

　　它在BPM套件之外提供了一個獨立的控制和管理層。這允許IT小組更好地管理他們所擁有和維護的服務的政策和資源。

　　SOA還支援從BPM套件中獲得對它所連接配接到的系統的更好可見度。IT小組可以在服務注冊庫中注冊服務，流程開發人員(甚至可能是業務分析師)可以在建構流程時浏覽這樣的注冊庫。這確定了服務可以被正确地使用和重用，而且通常簡化了業務流程，因為使用正确的服務可以将流程本身的複雜性降至最低。

　　無疑，這些優點隻有在IT基礎架構足夠複雜，并且/或者BPM項目達到一定的範圍和規模時才能顯現出來。是以，在很多情況下，應該首先開發出BPM，而将SOA元件留待以後考慮。

　　最好的方法是一開始就讓業務運作團隊和IT企業架構小組保持良好的對話，并針對未來進行規劃，同時支援戰術性執行。這就需要正确地組合産品。例如，BPM套件本身應該能夠提供豐富的連通性，以便無需全面應用完善的SOA來使得BPM運作，這一點非常重要。類似地，BPM套件應該支援SOA，這樣BPM與SOA才不至于存在于獨立的豎井中，這也很重要。