BPM陣營通常聲稱，SOA對于實現BPM來說不是必需的。只需部署一個BPM套件，就可以更快地實現目標而不會帶來多少復雜性。SOA陣營則注重于如何從一般意義上解決企業IT的復雜性。該陣營通常聲稱BPM是SOA的一個特性，但是它是SOA解決方案的一部分，而不是一個單獨的東西。當SOA領域的人士談到BPM時，該術語通常與服務編排或流程整合同義，而不強調對業務分析人員友好的建�；蛉藛T交互，而后者對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才不至于存在于獨立的豎井中，這也很重要。
文章來源于領測軟件測試網 http://www.k11sc111.com/
