SOA初級班(4)BPM與SOA從不同角度，形塑敏捷式企業

商務流程管理（Business Process Management，BPM）從程序的角度出發，最終目的是期望協助建立一路直通的作業環境，並建立持續改善程序的能力，提供企業因應市場變化，彈性調整的敏捷能力。

服務導向架構（Service-Oriented Architecture，SOA）則是從整體IT架構出發，企圖建立以合約為基礎，整合資訊與服務能力的發布平臺，目的同樣也是提升資訊系統的敏捷度，以應付市場競爭及持續的成長。

SOA與BPM兩者最終的目標都是建立企業的敏捷度，差別在於著眼的角度不同，操作的方法及方向也因此不同。

不能讓三個人生氣的，都不能稱之為程序
商務流程管理並不是一個新興的課題，早在1990年代在哈佛商業評論中一篇標題為《The Principles of Scientific Management》的文章中，就提出了商務流程再造（Business Process Reengineering，BPR）的概念。它的重心在建立企業內部的管理紀律，透過不斷調整的商業程序，推動企業管理的效率。

經營管理大師Michael Hammer在1996年發表的《Beyond Reengineering》中曾經對程序（Process）這個字眼提出很精闢的見解：「凡是不能讓三個人生氣的，都不能稱之為程序。」

之所以會讓人「生氣」，是因為彼此的立場。在一個人的情境下，沒有立場的問題；兩個人的情境，沒有少數或多數的問題，只能選擇合作或互不往來，也很難生氣；但是當第三個人出現時，就會有門戶之見和爭取多數支持的情況，這個時候就必須制定遊戲規則，程序也就跟著來了。遊戲規則很難盡如人意，因此不滿意程序的人，便會為此感到氣餒。

嚴格來說，程序的建立終究是為了達成商業目的，透過程序的制定，決定了要達成這個目的所需實踐的一連串工作，而進行這些工作勢必牽涉相關的參與者。這些參與者可能是人員，也可能是一些推動商務經營的系統。

整合技術扮演重要關鍵
工作流程引擎是啟動商務流程管理能量的重要因素，而其他相關的啟動技術還包括了像電子郵件和簡訊此類訊息傳遞及發布的平臺、文件管理平臺、商務規則建立、儲存及管理的環境、視覺化的程序建置工具等。

而這當中，SOA也會是一個啟動的技術，因為透過鬆散架構及單元獨立概念為基礎的服務，可以配合商業程序自由調整，並充分反應市場的變動。

而整合能力的強弱，是評選BPM平臺的重要指標。這是過去純以工作流程（Workflow）為主的產品最大的弱點，唯有涵蓋了整合能力的工作流程產品，才有資格晉升到BPM領域。

談到企業整合，絕對不能不談到XML，它在整合技術的演進過程中扮演著催化劑的角色。XML提供一個描述整合資料的標準基礎，也讓後續產生的Web Services相關標準，能以很低的門檻提供不同平臺互通的可能性。

進而從訊息的觀點產生出所謂企業服務匯流排（Enterprise Service Bus，ESB）的概念，整合訊息交換作業。再延伸到企業事件驅動架構（Event Driven Architecture，EDA），以事件的方式更主動地推動整合服務。

當整合的動作從資料進展到作業程序，BPM平臺就擔負起重要的角色，因此BPM產品幾乎都強調與某些主流系統的銜接能力。這些BPM平臺不論是採取鬆散結合或是緊密整合的策略，多半都不會少掉XML和Web Services這兩方面的處理能力。

整合能力的完備是評判企業建立服務導向架構能否成功的重要關鍵，在缺乏整合能力的情況下，很可能讓推動服務導向架構的工作到最後只是Web Services化，難以提供企業經營上需要的敏捷能力。

而良好的服務導向架構，又能協助企業推動更好的資訊整合環境。因此這兩者間可以說互為因果，一旦能正確地起頭，就有機會朝正向循環的方向前進，持續改善企業資訊服務架構。

BPM和SOA之間的配合
在定義商務程序的過程中，一般會期望能以標準的描述方式定義商務程序。雖然我們可以透過BPM平臺提供的視覺化模型建立工具，輕鬆建立起作業程序的架構，但很多時候這些作業程序可能會有跨平臺的需要，例如我們期望類似的程序能在夥伴的環境中實踐。因此能否順利地交換這個模型，有時會是很重要的需求。

由於服務導向架構是以合約及標準為基礎，因此描述商務程序也可以採用相同的精神。業界由Microsoft、IBM等主流廠商所合作制定的BPEL4WS，就是以Web Services的描述語言為基礎所描述商務程序的標準，讓商務程序能夠易於以服務的方式表現。

進到執行的階段，服務導向架構所強調的合約精神及在整合作業上提升的效度，可以讓執行的工作更為順暢，進而影響到作業監控實施的難易度。合約的協助使我們可以更容易地建立監控機制，以標準的作業方式檢視商務程序中資料的內容及動向。

而從服務導向架構在建立服務的過程中，我們也可以看到商業流程及邏輯的明確與否，也關鍵性地影響到每一個服務本身是否易於被重覆使用、是否符合商業意義。

換句話說，SOA會因為BPM的效益而有更佳的表現，相對的，SOA技術也讓BPM更容易實踐。兩者間在操作的手法上有許多相似之處，而它們在呈現的效果上也常會是一體兩面，一個著重在商業意涵上，一個則著重在資訊技術的運用上。

SOA的實踐以BPM的執行成果為指標
完整的BPM平臺除了要面對流程模型建立、模擬、人力工作流程等需求外，也必須具備有足夠基礎的企業應用整合能力，並充分管理商務流程的生命周期。

而在作業程序同時會牽涉到合作夥伴的情況下，相關的夥伴管理功能也可能是一個重要的項目，進而推展到B2B 的作業情境。

當然商務規則的處理，檢視作業進展和績效的入口網站技術也會是很重要的成員。而這些功能都可以因為SOA而有更好的表現，同時它們也可以做為檢視SOA成果很重要的指標或工具。

討論BPM這個主題時，很難不討論服務導向架構。而服務導向架構的實踐，也幾乎都會以BPM的執行成果做為評斷成功與否的重要指標。

透過良好的BPM平臺的協助，一方面可以支援整合及流程改善，另一方面也能幫助SOA，建立組合式的應用程式──也就是前述由應用程式及資料服務包裝成商業服務的成果。