本文探讨了服務導向架構(SOA)与企业流程管理(BPM)的关系及其对企业的影响。SOA作为一種整合資訊及应用的服务平台，而BPM则从经营管理和业务角度出发，两者共同提高了企业的灵活性与效率。
[quote]這個題目一口氣出現了三個專有名詞，所以在談這個題目之前我想我有必要先解釋何謂ESB/SOA及BPM，由於相關專業的文章已經非常的多，在此僅做些概念性的介紹。
服務導向架構(SOA)
我們先從大家較為熟悉的SOA談起，SOA就是「服務導向架構」(SOA, Service-Oriented Architecture)其中的Service大致可以說是企業的應用程式服務。我們可以和「物件導向程式設計」(OOP , Object-Oriented Programming)來做比較，OOP希望能透過物件化的程式設計來增進軟體程式元件模組化的程度，兩者均有一個重點就是希望提高服務或程式的重複使用率(re-use)，進而提高效率；OOP是以程式類別(class)為基礎，而SOA則是將重複使用的層次提高至應用程式層級，透過合約及網路的標準將應用程式包裝成可重複使用的商業服務。綜合來說是希望建構一個鬆散耦合的系統架構，能將應用程式及資料包裝成一個個的商業服務，而服務之間分享資料的綱要，以合約的方式呼叫及使用該服務。
企業服務匯流排(ESB)
ESB全名為Enterprise Service Bus，本質上是一個含有通訊基礎設施的服務容器，一般習慣在SOA的參考架構內將ESB定義在顯著的地位上。ESB是連接導向的 (Connectivity-Oriented)，它是負責管理並銜接SOA架構下的各種應用服務。
而ESB與SOA的關係由「Bus」與「Architecture」的差異就可感覺出企圖心的差異：ESB提供的是較具體較明確的運輸載具(公車)與路線，而SOA想解決的則是架構性的問題。好比在設計園區的交通網絡架構時，固定路線的交通車（小巴）是一種可考量的普遍選擇但卻不一定是唯一的選擇。對於特殊地區特殊需要的園區而言，或許地鐵、人員輸送帶、直升機等會是更好甚至是不得不的選擇。ESB注重的是架構一個可運行無礙的公車路線與站牌交通網。SOA則是除了交通網的建造外更要確保既有與未來要進駐之廠商需能符合這個交通網的交通相關規範。
企業流程管理(BPM)
最後來介紹「企業流程管理」(BPM, Business Process Management)。相對於SOA是由下而上從IT架構面著手，BPM的概念是由上而下從經營管理面(業務及程序)著手，從流程的角度出發，建立並持續改善企業流程，因應多變的組織模式以及隨時調整營運模式的問題。而一個完善的BPM系統不僅能提供商業流程所需要的規劃、監控及改善功能，更要能提供當流程是在跨異質系統時的資訊交換的支援能力。
由以上當可感覺出ESB/SOA的理想與BPM的部份理想相當接近：兩者均能提升企業因應環境及市場變化的適應能力，提高企業的敏捷度，將各資訊平台當作支援企業的資訊服務。只不過兩者經由不同的角度切入，SOA是從整體的IT架構下為基礎建立起一個整合資訊及應用的服務平台，而BPM則將IT、User及Business整合，以塑造快捷商業流程並加強管理，也能提供跨異質系統的整合能力。
BPM早就存在
歷史事實是，在沒有SOA之前，BPM產品就已經出現並成功應用。好比國光號不會因為高速公路封閉就因此停開，因為還有省道等替代道路可用，只不過走省道會比較慢比較耗油因此可能得調整票價與班次時間。同理，沒有ESB/SOA也不會因而無法做BPM。沒有ESB/SOA則當BPM的流程需要跨系統傳遞時就需依靠較傳統的EAI方式來開發，有了ESB/SOA則在跨系統部分的整合開發就會簡單與標準化的多。好比沒有統一的portlet標準前，EIP(Enterprise Information Portal)要顯示其他系統的訊息都得從頭客製（短則一週長則月餘），有了portlet後則只要把各系統提供的既有portlet掛到EIP上即可立即顯示（deploy與調整平均半小時）。
不過，好比宣稱有提供portlet的系統不見得剛好有提供所需顯示於EIP上資訊的portlet，比方某HR系統有提供組織圖、公司行事曆等的 portlet，但卻不見得會提供員工修改個人資料、薪資查詢、獎懲查詢等的portlet，因此當有需求在EIP上顯示相關資訊時那只有兩個方法：一是走回老路用EAI的方式，另一種則是對HR系統客製新的所需的符合標準的portlet。若僅為解決單一一次性的需求，前者技術上使用直接抓DB或是 iFrame的方式可能比用portlet快的多，但是若哪天換了portal或是其他系統也剛好需要，那就得重新review
有了ESB/SOA也不代表剛好BPM所需要的service已經打包好等人用，只不過有了SOA，BPM與各系統就有了比較一致統一的溝通方式，不管是web service或是ESB等，BPM導入廠商不用再得RFC、MQ、Store Procedure等不同介面樣樣精通才能取得不同系統的資訊，因此導入跨系統BPM時的導入障礙與溝通曲線會因此大幅降低。
之前我在BPM會不會引起內部革命中曾提過，Business Process Refine是BPM重要精神之ㄧ，而對一個跨系統的BPM而言，要能靈活Refine可不是一件簡單的事，在SOA的概念架構下建立的BPM更能展現整合能力及系統的彈性；而從另個角度看去，理想的SOA架構，更必須仰賴BPM依照其業務需求的服務(不僅是制式的或是彈性變化大的服務) 有效並且「有意義」地串聯起來，因此也增加了Business Process Refine的彈性及應變效率。
我為何特別強調「有意義」呢？是因為我認同所謂「應用比平台更重要」的這個說法，任職於IBM的J2EE顧問Bobby Woolf曾經寫了一篇文章，認為單純以連接導向但無商業價值建立起平台是值得再重新審視的策略。這是因為在還沒有產生商業價值之前就已經耗費了相當的成本，更何況那些未來不見得全部是你所能預見的。當然，平台絕對是重要的，好的平台目的就是要讓應用運作的更好，SOA和BPM的協調合作就是能夠建立起優秀整合能力的平台及動態地提供商業應用，這就是為什麼我要強調SOA架構下的BPM能夠有效率並且「有意義」地串聯起應用服務。
綜觀SOA及BPM在台灣市場上雷聲大雨點小，雖然近年火熱但企業多半還是抱著觀望並保留的態度，但其實在國外兩者早已經行之有年且成功應用，我想台灣企業應該要正式並且重視SOA及BPM了。
本文由超義軟體工程師葉永隆與李仰哲合作完成。如果想與專欄作者有進一步的討論，歡迎來信。
from [url]http://www.zdnet.com.tw/enterprise/column/bpmtalk/0,2000088808,20127340,00.htm[/url]
[/quote]
服務導向架構(SOA)
我們先從大家較為熟悉的SOA談起，SOA就是「服務導向架構」(SOA, Service-Oriented Architecture)其中的Service大致可以說是企業的應用程式服務。我們可以和「物件導向程式設計」(OOP , Object-Oriented Programming)來做比較，OOP希望能透過物件化的程式設計來增進軟體程式元件模組化的程度，兩者均有一個重點就是希望提高服務或程式的重複使用率(re-use)，進而提高效率；OOP是以程式類別(class)為基礎，而SOA則是將重複使用的層次提高至應用程式層級，透過合約及網路的標準將應用程式包裝成可重複使用的商業服務。綜合來說是希望建構一個鬆散耦合的系統架構，能將應用程式及資料包裝成一個個的商業服務，而服務之間分享資料的綱要，以合約的方式呼叫及使用該服務。
企業服務匯流排(ESB)
ESB全名為Enterprise Service Bus，本質上是一個含有通訊基礎設施的服務容器，一般習慣在SOA的參考架構內將ESB定義在顯著的地位上。ESB是連接導向的 (Connectivity-Oriented)，它是負責管理並銜接SOA架構下的各種應用服務。
而ESB與SOA的關係由「Bus」與「Architecture」的差異就可感覺出企圖心的差異：ESB提供的是較具體較明確的運輸載具(公車)與路線，而SOA想解決的則是架構性的問題。好比在設計園區的交通網絡架構時，固定路線的交通車（小巴）是一種可考量的普遍選擇但卻不一定是唯一的選擇。對於特殊地區特殊需要的園區而言，或許地鐵、人員輸送帶、直升機等會是更好甚至是不得不的選擇。ESB注重的是架構一個可運行無礙的公車路線與站牌交通網。SOA則是除了交通網的建造外更要確保既有與未來要進駐之廠商需能符合這個交通網的交通相關規範。
企業流程管理(BPM)
最後來介紹「企業流程管理」(BPM, Business Process Management)。相對於SOA是由下而上從IT架構面著手，BPM的概念是由上而下從經營管理面(業務及程序)著手，從流程的角度出發，建立並持續改善企業流程，因應多變的組織模式以及隨時調整營運模式的問題。而一個完善的BPM系統不僅能提供商業流程所需要的規劃、監控及改善功能，更要能提供當流程是在跨異質系統時的資訊交換的支援能力。
由以上當可感覺出ESB/SOA的理想與BPM的部份理想相當接近：兩者均能提升企業因應環境及市場變化的適應能力，提高企業的敏捷度，將各資訊平台當作支援企業的資訊服務。只不過兩者經由不同的角度切入，SOA是從整體的IT架構下為基礎建立起一個整合資訊及應用的服務平台，而BPM則將IT、User及Business整合，以塑造快捷商業流程並加強管理，也能提供跨異質系統的整合能力。
BPM早就存在
歷史事實是，在沒有SOA之前，BPM產品就已經出現並成功應用。好比國光號不會因為高速公路封閉就因此停開，因為還有省道等替代道路可用，只不過走省道會比較慢比較耗油因此可能得調整票價與班次時間。同理，沒有ESB/SOA也不會因而無法做BPM。沒有ESB/SOA則當BPM的流程需要跨系統傳遞時就需依靠較傳統的EAI方式來開發，有了ESB/SOA則在跨系統部分的整合開發就會簡單與標準化的多。好比沒有統一的portlet標準前，EIP(Enterprise Information Portal)要顯示其他系統的訊息都得從頭客製（短則一週長則月餘），有了portlet後則只要把各系統提供的既有portlet掛到EIP上即可立即顯示（deploy與調整平均半小時）。
不過，好比宣稱有提供portlet的系統不見得剛好有提供所需顯示於EIP上資訊的portlet，比方某HR系統有提供組織圖、公司行事曆等的 portlet，但卻不見得會提供員工修改個人資料、薪資查詢、獎懲查詢等的portlet，因此當有需求在EIP上顯示相關資訊時那只有兩個方法：一是走回老路用EAI的方式，另一種則是對HR系統客製新的所需的符合標準的portlet。若僅為解決單一一次性的需求，前者技術上使用直接抓DB或是 iFrame的方式可能比用portlet快的多，但是若哪天換了portal或是其他系統也剛好需要，那就得重新review
有了ESB/SOA也不代表剛好BPM所需要的service已經打包好等人用，只不過有了SOA，BPM與各系統就有了比較一致統一的溝通方式，不管是web service或是ESB等，BPM導入廠商不用再得RFC、MQ、Store Procedure等不同介面樣樣精通才能取得不同系統的資訊，因此導入跨系統BPM時的導入障礙與溝通曲線會因此大幅降低。
之前我在BPM會不會引起內部革命中曾提過，Business Process Refine是BPM重要精神之ㄧ，而對一個跨系統的BPM而言，要能靈活Refine可不是一件簡單的事，在SOA的概念架構下建立的BPM更能展現整合能力及系統的彈性；而從另個角度看去，理想的SOA架構，更必須仰賴BPM依照其業務需求的服務(不僅是制式的或是彈性變化大的服務) 有效並且「有意義」地串聯起來，因此也增加了Business Process Refine的彈性及應變效率。
我為何特別強調「有意義」呢？是因為我認同所謂「應用比平台更重要」的這個說法，任職於IBM的J2EE顧問Bobby Woolf曾經寫了一篇文章，認為單純以連接導向但無商業價值建立起平台是值得再重新審視的策略。這是因為在還沒有產生商業價值之前就已經耗費了相當的成本，更何況那些未來不見得全部是你所能預見的。當然，平台絕對是重要的，好的平台目的就是要讓應用運作的更好，SOA和BPM的協調合作就是能夠建立起優秀整合能力的平台及動態地提供商業應用，這就是為什麼我要強調SOA架構下的BPM能夠有效率並且「有意義」地串聯起應用服務。
綜觀SOA及BPM在台灣市場上雷聲大雨點小，雖然近年火熱但企業多半還是抱著觀望並保留的態度，但其實在國外兩者早已經行之有年且成功應用，我想台灣企業應該要正式並且重視SOA及BPM了。
本文由超義軟體工程師葉永隆與李仰哲合作完成。如果想與專欄作者有進一步的討論，歡迎來信。
from [url]http://www.zdnet.com.tw/enterprise/column/bpmtalk/0,2000088808,20127340,00.htm[/url]
[/quote]
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
