BPM與工作流程相關標準組織
想深層了解一個專業的產業發展,透過產業標準組織是一個不錯的方式。對技術底層感興趣的BPM技術人員來說,以下的清單可以作為探索的起點。
組織名稱 | 組織全名與網址 | 與BPM相關之標準 | 說明 |
WfMC | Workflow Management Coalition http://www.wfmc.org/ | Workflow Reference Model | 工作流程系統模組架構的參考模型 |
XPDL | XML - Process Definition Language | ||
WfXML | Workflow XML | ||
ASAP | 主持人為WfMC工作小組成員之一,但此工作放在OASIS,請參閱OASIS的項目 | ||
WAPI | Workflow API | ||
OASIS | Organization for the Advancement of Structured Information Standards http://www.oasis-open.org/ | ebXML – BPSS CPA CPP | e-Business using XML – BP Specification Schema Collaboration Protocol Agreements Collaboration Protocol Profile |
BPEL | Business Process Execution Language | ||
BTP | Business Transaction Protocol | ||
ASAP | Asynchronous Service Access Protocol | ||
UDDI | Universal Description, Discovery and Integration (從UDDI.org 併入OASIS) | ||
WS-CAF | OASIS Web Services Composite Application Framework | ||
WS-RM | OASIS Web Services Reliable Messaging | ||
UN/CEFACT | United Union, Centre for Trade Facilitation and Electronic Business http://www.unece.org/cefact | ebXML | (參考OASIS的 ebXML部分) |
OMG | Object Management Group http://www.omg.org/ | UML | 其中的Activity diagram 可用來描述企業流程的部分構面 |
BPMN | Business Process Modeling Notation | ||
BPRI | Business Process Runtime Interfaces | ||
BPDM | Business Process Definition Meta-model | ||
BSBR | Business Semantics of Business Rules | ||
OSM | Organization Structure Metamodel | ||
BRM | Business Rules Management | ||
BPMI | Business Process Management Initiative http://www.bpmi.org/ | BPMN BPML BPQL | (2005年6月已併入 OMG) |
W3C | World Wide Web Consortium http://www.w3.org/ | WS-CDL | WS-CDL Web Services Choreography Description Language |
WSDL | Web Service Definition Language | ||
SOAP | Simple Object Access Protocol | ||
HTTP | Hyper Text Transfer Protocol | ||
OAGi | Open Application Group http://www.openapplications.org/ | OAGIS -- BODs | Open Applications Group Integration Specification – Business Object Documents |
RosettaNet | RosettaNet http://www.rosettanet.org/ | RosettaNet -- PIPs | RosettaNet – Partner Interface Processes |
Supply Chain Council | Supply Chain Council http://www.supply-chain.org | SCOR model | Supply-Chain Operations Reference Model |
表一:現行BPM與工作流程技術標準一覽表
WfMC 是比較專注於工作流程的組織,它的WfMC workflow reference model是最常被引用的工作流程管理系統的參考模型。雖然WfMC的工作小組數目較少,但因為起步較早,旗下的 XPDL與WfXML標準,有相當多的工作流程廠商支援。WfMC替工作流程的技術發展奠定了早期的基礎,它界定了BPM與工作流程領域的大框架,也持續不斷的推廣BPM與工作流程,讓眾人清楚這個領域的體系與架構。
OASIS與OMG的技術小組數目比較多,工作焦點也不僅限於狹義的工作流程技術。因為涵蓋的範圍較廣,而且背後的支援廠商規模較大,所以整體影響力也較大。OASIS旗下的BPEL取自IBM、微軟等公司,而ebXML則是OASIS與UN/CEFACT這兩個組織共同成立的工作小組。OASIS藉由充沛的技術發展動能,為工作流程技術領域開拓更大的視野,在流程定義格式、流程執行層面,以及複雜的流程互動機制等領域,提供了寶貴的技術解決方案。
OMG在BPM領域掌握了標準記號(notation),包含UML,以及從BPMI併進來的BPMN。同時,OMG也積極以塑模(model)的角度,切入工作流程定義的其他構面,如共通模型表示法BPDM[ ]、流程語意BSBR、組織架構OSM、業務規則BRM等等。OMG的強項之一就是在塑模(model)技術,它的UML廣受軟體領域接受;在BPM與工作流程的領域,OMG持續發展BPMN與等其他BPM各構面的塑模技術,未來將使BPM的其他構面(如業務規則,或組織架構)也能使用像UML或BPMN這種等級的表示記號來進行塑模,讓複雜企業流程的塑模工作更加容易而清楚明確。
W3C的強項在於 Web 領域,HTTP是最知名的代表作。而XML與Web Services 是BPM在SOA領域的基礎建設。其它相關的BPM技術,如 WS-CAF, WS-RM, WS-CDL等等,都奠基於W3C的 Web Services技術。
OAGi、RosettaNet,以及 Supply Chain Council,則是特定產業領域的代表。它們的貢獻在於替特定產業界定共通的BPM運作規範,也就是說,定義屬於他們產業特色的應用流程參考模型與共通的術語,讓這個特定產業在推展BPM時,就有基本的需求大綱與基礎架構,也讓同產業體系內的廠商可以透過共通的產業模型與共通術語溝通,避免不同BPM應用系統之間產生各自為政而無法互通的障礙。如同前文所述,RosettaNet在電子商務領域已經廣為人知,SCOR模型則在於物流領域。雖然OAGi在國內的能見度沒有 RosettaNet高,但它涵蓋的範圍相當深遠,號稱涵蓋電子商務、製造、物流、航太、汽車、醫藥、零售、能源等32種產業。以OAGi 9.0版為例,就涵蓋61種流程情境(scenario definitions,像是訂單管理、應收帳款、供應鏈整合、銷售管理、客戶服務)與434種商業文件(BODs, 像是訂貨單、維修單、撿貨單、零件物料清單等,在流程當中傳遞的文件)的正規定義。
表一列出的各項技術標準,是以標準組織為分類依據,我們再以其他觀點來呈現其中幾個重要技術標準,以便讀者能夠更清楚了解這些標準的定位。
功能類別 | 功能目的 | 技術標準 |
流程查詢 Discovery | 透過查詢機制,取得服務流程的基本資料 | UDDI LDAP DISCO |
產業間流程互動機制 B2B collaboration | 使同一個特定應用產業的流程具備基礎的參考模型與術語 | RosettaNet 的PIPs ebXML的CPA OAGIS的BODs EDI,SWIFT |
塑模方式與記號 Modeling | 提供標準記號(notation)與塑模技術 | OMG的UML、BPMN |
流程定義的語意與格式 Process Definition | 提供結構化的流程定義儲存格式,並且明確解釋每一個流程定義項目所代表的語意 | WfMC的 XPDL、WfXML OASIS的 BPEL,以及ebXML BPSS,ASAP, WS-CAF W3C的WS-CDL |
服務介面描述 Services | 定義結構化的格式,供軟體元件描述它所提供服務的內容與調用方式 | W3C的WSDL OASIS的ebXML CPP |
傳輸介面 Transport | 提供訊息的傳輸機制 | W3C的HTTP/SOAP OASIS的WS-RM |
表二:依功能分類的BPM/工作流程技術標準一覽表
圖一: WfMC技術小組提供的工作流程相關標準堆疊圖,2003年版本
服務導向的企業
過去幾十年間,企業經營的焦點隨著市場趨勢而演化,60年代談的是提升量產,70年代談的是降低成本,80年代談的是提升品質,90年代談的是產品推出速度,而跨入21世紀,談的是如何給客戶更多樣的服務。不管重心怎麼改變,在21世紀之前,改善的重心仍落在產品實體;直到21世紀,重心已開始從產品延伸到購買產品的顧客,強調顧客是怎麼樣獲得產品與服務。
年代 | 經營管理重心 | 解決方案 | |
1960~ | 提升產量 | Quantity: Make more | 自動化生產 |
1970~ | 成本與價格 | Cost: Make it cheaper | 採購與供應鏈 ERP,SCM |
1980~ | 產品品質 | Quality: Make it better | 品管技術 TQM |
1990~ | 產品推出速度 | Lead Time: Make it quicker | 產品開發管理 PLM,PDM |
2000~ | 服務內容多樣化 | Service: Offer more | 服務內容與流程 BPM,SOA |
表三:各年代的企業經營管理重心
為了提供多樣化的服務,許多企業活動將被解構後再重組為新的營運模式,而這代表位居幕後支援的IT技術,必須能迅速配合這樣的營運模式改變。也就是說,所有的IT技術與資訊系統,都能夠像變形蟲一樣,隨時解構後再重組,在短時間內提供新營運模式所需的資訊服務,這包括企業後台營運所需的資訊系統,以及面對客戶所需的前台服務介面。
在十倍速的時代,企業無法等待。傳統為了新營運模式而大規模修改 (而非重組) 資訊系統的方式,過於牛步化無法滿足要求。下一節提到的SOA架構,替服務導向的企業,提供了很好的解答。
天生一對的企業流程管理(BPM)與服務導向架構(SOA)
SOA的IT技術本質單純而不難理解,個別的技術元素分別理解還算容易。對於SOA,大家聯想到的就是 Web Services,談到Web Services,我們就直接脫口而出:WSDL、UDDI,以及SOAP,然後就是一系列的WS-* 的技術標準。對很多人來說,只了解個別技術單元,並無法領會到SOA世界的美好。就好像只看得到調色盤的每個顏色,卻看不到美麗動人的畫作。所以,讓我們先把無趣的技術名詞擺一邊,這無助於我們了解SOA的美好世界。
首先,我們需先認識SOA世界裡的企業流程運作方式,以及SOA的技術元素可以互相彼此串接而形成豐富的生態;如此,就可知道為什麼BPM與SOA是天生一對 -- SOA 架構總存在美妙的答案來滿足BPM變化多端的環境。
一般來說,真實世界的BPM,具有以下的IT需求特徵:
- 它的運作是分散式的:多數企業流程都是由多個參與者共同執行,參與者可能來自不同辦公室,甚至不同的地域區域,打破部門藩籬,甚至跨越公司的疆界;因此,跨網際網路環境的應用系統支援,以及網路環境下的安全性,都必須列入考量。
- 它可以進行工作協調與應用程式整合:大部分的企業流程並不只是執行單一業務功能,而是多個業務功能互相協調後的成果;因此,原本獨立支援某項業務運作的應用系統,也必須跟其他業務的應用系統相互整合。
- 它是動態的系統:企業流程中的各項元素經常動態改變。工作串連方式會隨著環境改變、人員角色扮演會異動,工作的執行地點也會改變。因此,BPM環境中的應用程式模組,必須演化成快速適應變動的動態系統,可以輕易透過設定或組態的改變行為模式,甚至調整執行地點,以因應企業流程的變動。
- 它的構成元素種類繁多而複雜:BPM系統內含分布於各模組的企業邏輯與規則、各種不同安裝與監管模式的應用模組,以及眾多模組之間的串聯與相依關係設定。因此,BPM環境中的軟體模組,需要讓模組變得可以被BPM組態機制管理,這包含模組的啟用停用、健康狀態回報,以及系統安全政策,都應有一致的管理方式與技術標準。如此,整個複雜的BPM環境運作才可列入掌握而不致失控。
- 它可以漸進式地成長:企業可以從最簡單的BPM活動開始著手,再演進到成熟複雜的BPM系統;因此,整個系統架構必須能提供清楚的進步藍圖,允許企業按部就班投入IT資源,並逐漸提升BPM成熟度來執行BPM。
以上五個特徵,剛好可用來陪同我們探索SOA的技術世界。
針對特徵一,SOA 技術架構可提供安全的網路傳輸與執行環境。主要技術有二:一是軟體模組互相通訊時,所需的保密需求,這可由WS-Security來達成。另一個則是組織成員在環境中的權限控管方式,這可在SOA架構內,採用LDAP、整合單一帳號登入、PKI架構與數位簽章等機制來配合。
第二個特徵引發的議題是SOA工作協調與應用系統整合。傳統應用模組在SOA的世界裡,可以採用SOA規定的服務介面(Services Interfaces)對外開放模組的功能。應用模組之間,透過SOA的服務介面標準互傳資料,就是最簡單的Web Services應用案例。此機制的主要意義在於:所有SOA內的應用模組,只要提供SOA的標準服務介面,就可以不受開發語言限制,互相呼叫或傳遞資料。這裡的服務介面,講的就是WSDL(Web Service Description Language);而SOAP(Simple Object Access Protocol)則是規定應用模組之間互相呼叫或互傳資料時的封包格式。至於WSDL或SOAP的內容與格式應該長怎樣,大部分技術人員可以讓中介軟體或者EAI系統代勞,透過service adaptor 直接把傳統應用模組包成 Web Services模組,並不需煩惱內容的細節。
第三個特徵引發的議題是 SOA的服務組合彈性與鬆散耦合(loosely couple)的特性。SOA內的應用模組若要能輕鬆改變組合方式,或者改變執行位置,就要藉助SOA的兩個技術特性:鬆散耦合,以及UDDI(Universal Description, Discovery, and Integration)機制。因為鬆散耦合,所以某一模組抽離或加入系統,並不影響其他模組;因為有UDDI機制,所以新應用模組加入時,只需跟UDDI伺服器登記新服務的介面與所在地點,即可被其他應用模組搜尋到,並且開始互動。因為有UDDI,所以當某項應用模組遷離位置,原有使用此應用模組的其他模組,可以透過UDDI找到服務的新位置,然後用新位置連結即可。這種特性滿足「經常需要把服務節點拆解再重組」的BPM服務導向經營模式。
第四個特徵談到的是可管理的SOA Web Services。這是系統管理與軟體管理的議題,雖然目前沒有統一的標準來規範管理軟體與被管理模組的行為,但目前稍具知名度的SOA環境(特別是application server)多半會提供系統管理工具給系統管理員使用,協助管理SOA架構下所有列管模組的安裝、移除、啟動、停用,以及應用模組的狀態監控與安全機制。
第五個特徵,談的是SOA 技術架構是模組化又可彈性串接的特性,在原有SOA環境加入新的技術模組,即可漸進式提升BPM技術的成熟度。我們從ZapThink [ ]整理的SOA藍圖中,可以得知達到不同SOA成熟階段所需具備的SOA技術。舉例來說,假設SOA有階段實施的計畫,那中間過程可以從「點對點整合」開始,進步到「提供鬆散耦合的服務」,再來是「穩定而可搜尋發現的服務」,接著「提供可組裝與再利用的服務」,進而達到最終目標—「全公司的SOA」。當然,也可從藍圖中得知,不同SOA階段所能獲得的投資回報(ROI),剛開始只能是「降低應用程式的維護成本,達成點對點的整合」,接著是「透過服務再利用提昇效率」,再來是「提升管理能見度與控制力」,最後才是「改善組織的敏捷度」。
結語
其實,即使是資深的BPM/SOA規劃者,想要跟決策主管解釋清楚SOA的博大精深以及其效用,都是很大的挑戰。主要原因在於其中大大小小的技術條目,以及其相當複雜的關聯。雖然大家都知道,畫出一張易懂的圖解,勝過千言萬語,然而好圖難求,幸好今年(2005)十月ZapThink公司推出一張令人深刻的SOA藍圖海報。這張嘔心瀝血之作,讓人能從各個構面、由入門到進階,逐步探索SOA的世界,而且過目難忘,卻又能夠不失BPM/SOA技術的深度與完整度,實在非常難得,在此推薦這張海報作為延伸閱讀,也當作本文的尾聲。
附註
1. T.H. Davenport and J.E. Short, "The New Industrial Engineering: Information Technology and Business Process Redesign,", Sloan Management Review, pp. 11-2, Summer 1990.
2. Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate ”, Harvard Business Review, Jul 1990.
3. Michael Hammer and James Champy, Reengineering the Corporation : A Manifesto for Business Revolution, Harpercollins, 1st ed.,May 1993.
4. Michael Hammer, Beyond Reengineering : How the Processed-Centered Organization is Changing Our Work and Our Lives, Collins, Sep 1997.
5. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kiffer Press, 1st edition, Jan 2003.
6. 參閱 Derek Miers, “BPM -- Too much BP, not enough of the M,” WfMC Workflow Handbook 2005, Future Strategies, 2005.
7. Web Services Orchestration,簡單說法:使用流程技術來描述並控制Web Services的調用順序,使多個Web Services依序發生,執行事先安排的工作順序。
8. Web Services Choreography,簡單說法:在跨流程的情境中,以Web Services技術,描述流程個體之間的訊息傳遞關係(多半是網狀結構),以及流程狀態的控制與查詢方式。
9. 參閱本文「天生一對的BPM與SOA」小節
10. BPDM的目的在於提供可通用於多種流程塑模方法的中介模型(meta-model),以便不同塑模方法產生的流程定義可以互相轉譯。如UML、BPMN,或者其他廠商的專屬表示法,能夠對照到此中介模型,然後互相轉譯;或者讓流程定義轉譯成底層的可執行格式,如BPEL原始碼,乃至於J2EE或 .NET的執行碼。 R. Schmelzer and J. Bloomberg, ZapThink's Service-Oriented Architecture Roadmap, URL: http://www.zapthink.com/report.html?id=ZTS-GI103