關於業務流程管理(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才不至於存在於獨立的豎井中，這也很重要。