BPM那些事儿——BPM与SOA的演进与展望
前言
BPM(企業(yè)流程管理，Business Process Management)技術(shù) 與 SOA (服務(wù)導(dǎo)向架構(gòu)，Service Oriented Architecture)各自歷經(jīng)多年的發(fā)展，至今成為廣為業(yè)界接受的技術(shù)架構(gòu)。本文將從 BPM & SOA 的歷史演進開始，深入淺出描述各標準的發(fā)展過程與彼此的關(guān)系，讓讀者輕松了解其應(yīng)用范圍與來龍去脈。另外，也將以相關(guān)標準組織的最新資料為基礎(chǔ)，介紹當前制定中的新技術(shù)標準以及其演進。
以流程為中心的管理思潮
BPM 的范疇涵蓋企業(yè)營運的各項構(gòu)面，如研發(fā)、生產(chǎn)、行銷、業(yè)務(wù)、人事、財務(wù)等企業(yè)營運活動，甚至往上下游擴及供應(yīng)商與經(jīng)銷商，以及客戶端的客服活動。訴求是企業(yè)應(yīng)以流程化的思考方向，串連原本各自獨立而未協(xié)調(diào)的營運活動，使串連后之營運活動成為具有步步加值效果的企業(yè)營運流程，并輔以各項管理手法使其落實運行，達成企業(yè)流程管理目標。
1990年麻省理工學(xué)院 Hammer、Champy，哈佛大學(xué) Davenport 等人，相繼在學(xué)術(shù)刊物發(fā)表企業(yè)流程再造(Business Process Re-engineering)觀念。1993年 Hammer ?與 Champy 繼續(xù)發(fā)表《企業(yè)再造》一書，強調(diào) BPR 的重要性，以及 IT 技術(shù)在 BPR 過程的角色，使 BPR 成為當時的熱潮。1997年，Hammer 又發(fā)表《企業(yè)再造之后》，宣告了流程化組織的必然性與重要性，并且預(yù)言 BPM/BPR 將改變?nèi)说墓ぷ鞣绞健?/p>
2003年，Smith 與 Fingar 發(fā)表《企業(yè)流程管理：第三波》，預(yù)言往后50年BPM仍將是企業(yè)經(jīng)營的重要議題，也指出21世紀BPM的型態(tài)與新特征，并給予可行的教戰(zhàn)守則，更羅列數(shù)十個企業(yè)運行BPM的實際案例與經(jīng)驗，讓推行BPM的藍圖更加具體，使本書成為當年企管領(lǐng)域的暢銷書，讓BPM的風(fēng)潮持續(xù)不滅。
BPM的推行觀念的改變與進程
根據(jù)1993年《企業(yè)再造》一書的調(diào)查，當時企業(yè)推行 BPR/BPM 有高達5~7成的失敗率。因為這么高的失敗率，所以即使BPM是企業(yè)勢必要面對的議題，也讓他們把BPM的推展視為畏途，甚至抱持負面的看法。之后，整個BPM產(chǎn)業(yè)繼續(xù)歷經(jīng)十幾年的學(xué)習(xí)經(jīng)驗，與前仆后繼的推行案例，不斷從許多案例歸納關(guān)鍵的成功或失敗因素，讓推展BPM的藍圖逐漸浮現(xiàn)。在藍圖中，錯誤的作法逐步被修正，更多的BPM管理工具被界定(identified)出來而豐富了整個藍圖。眾人慢慢認同，一個成功的BPM推行，是由以下金三角共同構(gòu)成：
- 明確而有共識的組織流程規(guī)范
- 成熟的BPM軟件系統(tǒng)架構(gòu)與建置
- 企業(yè)主管與員工的認同與運行力
從變動幅度來看，以往革命性大刀闊斧的BPR(流程再造)口號，已轉(zhuǎn)變?yōu)闇睾偷腂PM(流程管理)實踐。這種務(wù)實的作法，事實上是察覺到組織變革、流程思考企業(yè)文化的形成，需要一年到數(shù)年的時間；革命性的快速改變，若無充分的準備與良好管理體質(zhì)，反而讓企業(yè)亂了原有的腳步。所以一步一腳印的務(wù)實作法，漸漸獲得認同。企業(yè)從核心BPM流程的落實與推行開始，逐步拓展到外圍系統(tǒng)與業(yè)務(wù)伙伴，將可降低失敗機率。
而從管理成熟度來看，過去企業(yè)推行BPM，多半以流程計算機化這種短程目標為主，卻忽略了BPM的終極目標在于「管理」，而非計算機技術(shù)，也非流程細節(jié)。所以高階經(jīng)營決策的需求常常被忽略而缺乏規(guī)劃。而因為缺乏指導(dǎo)目標，在BPM的需求導(dǎo)引過程當中，企業(yè)員工常會無明確的指導(dǎo)目標，而以為工作流程計算機化就是把自己手邊的工作巨細靡遺計算機化，而模糊了BPM的管理焦點。當這些與終極BPM管理目標無關(guān)的軟件需求被列入計畫討論，不僅模糊焦點，也無形地墊高BPM的整體成本。
事實上，BPM的管理可以歸納為以下幾個可逐步提升的層次，從這些層次也可了解一般組織推行BPM的成長歷程：
- 混沌階段：沒有明確的企業(yè)流程定義。
- 明文定義：具有書面的企業(yè)流程定義或標準作業(yè)程序，但沒有根據(jù)正規(guī)的記號(notation)，因此規(guī)則也許含混不清。
- 驗證與共識形成：定義的企業(yè)流程，通過公司組織政策的驗證，如質(zhì)量政策，市場策略，管理原則，并獲得高層決策通過，達成組織共識。
- 組織人員的流程準備：組織成員經(jīng)過教育訓(xùn)練，認同組織制定的企業(yè)流程，并且具備運行的能力，包含專業(yè)基本技能的養(yǎng)成，并習(xí)慣流程化、信息化的作業(yè)方式。
- 企業(yè)本身的流程準備度：現(xiàn)行的企業(yè)組織架構(gòu)，若與流程化的思考方式?jīng)_突，則應(yīng)及早準備組織架構(gòu)的調(diào)整，特別是毫無章法的職務(wù)與部門階層架構(gòu)(hierarchy)。良好的組織設(shè)置與權(quán)責(zé)劃分，可以使流程定義更為精簡易懂、便于遵循，也容易分析企業(yè)規(guī)則之間是否相互矛盾；同時可降低BPM軟件系統(tǒng)的開發(fā)成本。
- 采用標準的企業(yè)流程表示法：使用一致的標準記號與格式來表達企業(yè)流程的內(nèi)容。這里的標準記號應(yīng)該是廣被業(yè)界采用的格式，例如OMG在UML所定義的活動圖(activity diagram)、BPMI (現(xiàn)已并入OMG) 組織所定義的BPMN，以及OASIS組織的BPEL。當然，企業(yè)流程的內(nèi)容確實相當復(fù)雜，單一標準記號或格是通常只能描述部分構(gòu)面，所以仍會有些構(gòu)面暫時沒有業(yè)界共同認可的記號或格式可供選用。
- 流程自動化：使用軟件系統(tǒng)落實企業(yè)流程的運行流程。包括使用流程定義工具來定義企業(yè)流程內(nèi)容，以及使用工作流程管理系統(tǒng)(WfMS ? workflow management system)來運行定義的企業(yè)流程。
- 進度監(jiān)管：企業(yè)流程的運行進度可以被監(jiān)看(monitored)與追蹤管理。
- 流程集成：流程運行過程中，能進一步與其他內(nèi)外部的流程互通，或者與既有應(yīng)用系統(tǒng)(legacy system)交換資料，以延伸流程的觸角，發(fā)揮綜效。
- 流程績效評量：企業(yè)流程的運行效能可以被測量(measured)，并且透過公式計算，以報表呈現(xiàn)有意義的管理指針。
- 流程分析與仿真：持續(xù)搜集企業(yè)流程的運行資料，分析組織的流程運行瓶頸，并回饋到流程定義，調(diào)整業(yè)務(wù)的運行方式。另外，也根據(jù)歷史資料與預(yù)測參數(shù)，透過仿真分析試算，比較不同流程調(diào)整方式所獲得的改善程度。
- 智慧型流程環(huán)境：透過流程資料的資料采擷(data mining)，主動分析流程統(tǒng)計數(shù)據(jù)，并回饋至流程系統(tǒng)。舉例來說，在客服流程系統(tǒng)中，主動歸納顧客過去使用服務(wù)的頻率與分布狀況，歸納未來的趨勢與規(guī)律(pattern)，并根據(jù)現(xiàn)有流程環(huán)境的現(xiàn)況(如現(xiàn)有承接量，以及可動用的客服人力資源)，自動調(diào)度客服人力分配策略，或向資源管理者建議客服人力調(diào)度策略。
企業(yè)推展BPM不見得要立刻從IT工具的選擇開始，前期的充分準備可縮短軟件系統(tǒng)的分析時間。企業(yè)流程自動化之后，則有更多的管理輔助工具可供搭配，強化企業(yè)流程的運行績效，提升企業(yè)的BPM成熟度。企業(yè)決策主管則可從以上層次分析，清楚得知達成不同層次的BPM進程，所能獲得的管理效益，以及相對的BPM技術(shù)解決方案需求。
BPM的技術(shù)現(xiàn)況與趨勢
BPM的其中一個技術(shù)構(gòu)面是流程，它的IT技術(shù)解決方案的來源可追溯到1970年代晚期的文檔傳閱(routing)應(yīng)用系統(tǒng)，主要目的是讓商業(yè)文檔與圖象能在不同計算機間傳遞，使文檔能從輸入或掃描人員，傳遞到審核人員與其他角色。典型的應(yīng)用流程包括保險公司的保單資料處理作業(yè)，或者銀行的融資申請與簽約作業(yè)。這些需求促成了工作流程(workflow)技術(shù)的崛起，而軟件業(yè)也開始把工作流程技術(shù)應(yīng)用到這類應(yīng)用系統(tǒng)，成為核心組件。
工作流程技術(shù)是中立的角色，隨著不同應(yīng)用領(lǐng)域的興起而有不同的運用方式，在辦公室自動化、公文系統(tǒng)、研發(fā)專案管理、制程管理、品保系統(tǒng)，或者客戶服務(wù)系統(tǒng)等等，都可以查找工作流程技術(shù)扮演的重要角色。即便是面對企業(yè)管理領(lǐng)域被炒得火熱的BPR/BPM，或者在IT/Web Services領(lǐng)域被當成新興技術(shù)議題討論的Web Services Orchestration、Choreography與企業(yè)流程運行語言(BPEL－Business Process Execution Language) ，只要詳細分析其技術(shù)本質(zhì)，仍不脫工作流程技術(shù)既有的范疇。這些當紅的企管或技術(shù)名詞，一旦底層抽離工作流程技術(shù)，就無法獨立存在。
然而，狹義的工作流程技術(shù)并不是推行BPM所需的IT技術(shù)的全部。早期工作流程技術(shù)與圖象掃描與辨識技術(shù)結(jié)合，造就了文檔圖象流程系統(tǒng)。近年，工作流程從BPM領(lǐng)域切入，成為解決方案的重要一環(huán)；狹義的工作流程技術(shù)，歷經(jīng)多年匯流了多項技術(shù)元素，成為當代的BPM解決方案，主要特色如下：
- IT技術(shù)面：采用工作流程技術(shù)為主體，結(jié)合入口網(wǎng)站(Portal)、企業(yè)應(yīng)用集成(EAI－Enterprise Application Integration)、報表與商業(yè)智慧(BI－Business Intelligent)工具、流程模型分析(process model analysis)、與仿真(simulation)技術(shù)。這些現(xiàn)成(COTS——commercial off-the-shelf)軟件組件結(jié)合運作，可大幅降低信息系統(tǒng)的建置成本、時程，以及開發(fā)風(fēng)險。?
- 管理活動面：可提供策略地圖、平衡計分卡、六個標準差、TQM等管理活動的必要管理信息，搭配合適的管理決策工具呈現(xiàn)企業(yè)整體的BPM成效。
- 貼近特定產(chǎn)業(yè)的流程需求：每個產(chǎn)業(yè)都有其特有的企業(yè)經(jīng)營模式與參考模型，如制造業(yè)、買賣業(yè)、醫(yī)療業(yè)、物流業(yè)等產(chǎn)業(yè)，都存在產(chǎn)業(yè)專屬的流程模型與標準。像是 RosettaNet 替電子商務(wù)交易的詢價、下單、交貨、付款等流程作業(yè)，制定了日常實際應(yīng)用的參考模型；而供應(yīng)鏈協(xié)會(Supply Chain Council)則在供應(yīng)煉與物流領(lǐng)域，制定SCOR流程運作模型(Supply Chain Operation Reference)。若流程定義工具能夠直接提供這些參考模型的語意支持，或者提供現(xiàn)成可套用的流程樣板(template)，將可以減少開發(fā)這些特定產(chǎn)業(yè)應(yīng)用所需的成本。
- 服務(wù)接取(access)面：解決方案能滿足不同的使用者，如習(xí)慣大量資料輸入作業(yè)的專業(yè)使用者、少量資料操作的一般使用者、偏重BPM績效報表的主管，或者行動裝置的使用者。也就是說，可提供不同的操作界面，如常規(guī)桌上型應(yīng)用程序、Web Browser應(yīng)用程序、PDA，或者Smart Phone等裝置，給參與BPM系統(tǒng)的各種人員使用。
- 交互情境面：BPM技術(shù)解決方案需同時兼顧「人對程序」、「人對人協(xié)同作業(yè)」，以及「程序?qū)Τ绦颉沟冉换デ榫场?/li>
鑒往知來，BPM解決方案的風(fēng)貌將持續(xù)納入更多的元素而顯得多樣化，不管是因應(yīng)管理哲學(xué)的革新、應(yīng)用情境的延伸，或者新技術(shù)的崛起，只要有道理，沒什么元素不可以納入的。雖然沒有一個獨立的BPM產(chǎn)品能同時滿足以上所有特色（事實上，企業(yè)BPM規(guī)劃者也不見得要貪心得一次全部用上），但企業(yè)BPM架構(gòu)規(guī)劃者，仍可根據(jù)BPM導(dǎo)入步驟，按部就班先進行組織改革與訓(xùn)練，然后根據(jù)管理需求與現(xiàn)有的IT解決方案，參考本文所述的各項BPM特點，逐一評估挑選合適的IT模塊，納入為自己企業(yè)量身打造的BPM運行藍圖。
由于BPM解決方案并不是一次到位的架設(shè)，而是持續(xù)多年的活動，因此整體BPM藍圖必須考慮分期開發(fā)，漸進導(dǎo)入的特性，建議BPM的IT規(guī)劃者應(yīng)參考本文稍后所提的SOA架構(gòu)當成藍圖的基礎(chǔ)。
PM與工作流程相關(guān)標準組織
想深層了解一個專業(yè)的產(chǎn)業(yè)發(fā)展，透過產(chǎn)業(yè)標準組織是一個不錯的方式。對技術(shù)底層感興趣的BPM技術(shù)人員來說，以下的列表可以作為探索的起點。
| 組織名稱 | 組織全名與網(wǎng)址 | 與BPM相關(guān)之標準 | 說明 |
| WfMC | Workflow Management Coalition http://www.wfmc.org/ | Workflow Reference Model | 工作流程系統(tǒng)模塊架構(gòu)的參考模型 |
| 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 可用來描述企業(yè)流程的部分構(gòu)面 |
| 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 |
表一：現(xiàn)行BPM與工作流程技術(shù)標準一覽表
WfMC是比較專注于工作流程的組織，它的WfMC workflow reference model是最常被引用的工作流程管理系統(tǒng)的參考模型。雖然WfMC的工作小組數(shù)目較少，但因為起步較早，旗下的XPDL與WfXML標準，有相當多的工作流程廠商支持。WfMC替工作流程的技術(shù)發(fā)展奠定了早期的基礎(chǔ)，它界定了BPM與工作流程領(lǐng)域的大框架，也持續(xù)不斷的推廣BPM與工作流程，讓眾人清楚這個領(lǐng)域的體系與架構(gòu)。
OASIS與OMG的技術(shù)小組數(shù)目比較多，工作焦點也不僅限于狹義的工作流程技術(shù)。因為涵蓋的范圍較廣，而且背后的支持廠商規(guī)模較大，所以整體影響力也較大。OASIS旗下的BPEL取自IBM、微軟等公司，而ebXML則是OASIS與UN/CEFACT這兩個組織共同成立的工作小組。OASIS藉由充沛的技術(shù)發(fā)展動能，為工作流程技術(shù)領(lǐng)域開拓更大的視野，在流程定義格式、流程運行層面，以及復(fù)雜的流程交互機制等領(lǐng)域，提供了寶貴的技術(shù)解決方案。
OMG在BPM領(lǐng)域掌握了標準記號(notation)，包含UML，以及從BPMI并進來的BPMN。同時，OMG也積極以塑模(model)的角度，切入工作流程定義的其他構(gòu)面，如共通模型表示法BPDM、流程語意BSBR、組織架構(gòu)OSM、業(yè)務(wù)規(guī)則BRM等等。OMG的強項之一就是在塑模(model)技術(shù)，它的UML廣受軟件領(lǐng)域接受；在BPM與工作流程的領(lǐng)域，OMG持續(xù)發(fā)展BPMN與等其他BPM各構(gòu)面的塑模技術(shù)，未來將使BPM的其他構(gòu)面(如業(yè)務(wù)規(guī)則，或組織架構(gòu))也能使用像UML或BPMN這種等級的表示記號來進行塑模，讓復(fù)雜企業(yè)流程的塑模工作更加容易而清楚明確。
W3C的強項在于Web領(lǐng)域，HTTP是最知名的代表作。而XML與Web Services是BPM在SOA領(lǐng)域的基礎(chǔ)建設(shè)。其它相關(guān)的BPM技術(shù)，如WS-CAF, WS-RM, WS-CDL等等，都奠基于W3C的Web Services技術(shù)。
OAGi、RosettaNet，以及Supply Chain Council，則是特定產(chǎn)業(yè)領(lǐng)域的代表。它們的貢獻在于替特定產(chǎn)業(yè)界定共通的BPM運作規(guī)范，也就是說，定義屬于他們產(chǎn)業(yè)特色的應(yīng)用流程參考模型與共通的術(shù)語，讓這個特定產(chǎn)業(yè)在推展BPM時，就有基本的需求大綱與基礎(chǔ)架構(gòu)，也讓同產(chǎn)業(yè)體系內(nèi)的廠商可以透過共通的產(chǎn)業(yè)模型與共通術(shù)語溝通，避免不同BPM應(yīng)用系統(tǒng)之間生成各自為政而無法互通的障礙。如同前文所述，RosettaNet在電子商務(wù)領(lǐng)域已經(jīng)廣為人知，SCOR模型則在于物流領(lǐng)域。雖然OAGi在國內(nèi)的能見度沒有 RosettaNet高，但它涵蓋的范圍相當深遠，號稱涵蓋電子商務(wù)、制造、物流、航太、汽車、醫(yī)藥、零售、能源等32種產(chǎn)業(yè)。以O(shè)AGi 9.0版為例，就涵蓋61種流程情境(scenario definitions，像是訂單管理、應(yīng)收帳款、供應(yīng)鏈集成、銷售管理、客戶服務(wù))與434種商業(yè)文檔(BODs, 像是訂貨單、維修單、撿貨單、零件物料列表等，在流程當中傳遞的文檔)的正規(guī)定義。
表一列出的各項技術(shù)標準，是以標準組織為分類依據(jù)，我們再以其他觀點來呈現(xiàn)其中幾個重要技術(shù)標準，以便讀者能夠更清楚了解這些標準的定位。
| 功能類別 | 功能目的 | 技術(shù)標準 |
| 流程查詢 Discovery | 透過查詢機制，取得服務(wù)流程的基本資料 | UDDI LDAP DISCO |
| 產(chǎn)業(yè)間流程交互機制 B2B collaboration | 使同一個特定應(yīng)用產(chǎn)業(yè)的流程具備基礎(chǔ)的參考模型與術(shù)語 | RosettaNet 的PIPs ebXML的CPA OAGIS的BODs EDI，SWIFT |
| 塑模方式與記號 Modeling | 提供標準記號(notation)與塑模技術(shù) | OMG的UML、BPMN |
| 流程定義的語意與格式 Process Definition | 提供結(jié)構(gòu)化的流程定義保存格式，并且明確解釋每一個流程定義項目所代表的語意 | WfMC的 XPDL、WfXML OASIS的 BPEL，以及ebXML BPSS，ASAP, WS-CAF W3C的WS-CDL |
| 服務(wù)界面描述 Services | 定義結(jié)構(gòu)化的格式，供軟件組件描述它所提供服務(wù)的內(nèi)容與調(diào)用方式 | W3C的WSDL OASIS的ebXML CPP |
| 傳輸界面 Transport | 提供消息的傳輸機制 | W3C的HTTP/SOAP OASIS的WS-RM |
表二：依功能分類的BPM/工作流程技術(shù)標準一覽表
圖一: WfMC技術(shù)小組提供的工作流程相關(guān)標準堆棧圖，2003年版本
服務(wù)導(dǎo)向的企業(yè)
過去幾十年間，企業(yè)經(jīng)營的焦點隨著市場趨勢而演化，60年代談的是提升量產(chǎn)，70年代談的是降低成本，80年代談的是提升質(zhì)量，90年代談的是產(chǎn)品推出速度，而跨入21世紀，談的是如何給客戶更多樣的服務(wù)。不管重心怎么改變，在21世紀之前，改善的重心仍落在產(chǎn)品實體；直到21世紀，重心已開始從產(chǎn)品延伸到購買產(chǎn)品的顧客，強調(diào)顧客是怎么樣獲得產(chǎn)品與服務(wù)。
| 年代 | 經(jīng)營管理重心 | 解決方案 | |
| 1960~ | 提升產(chǎn)量 | Quantity: Make more | 自動化生產(chǎn) |
| 1970~ | 成本與價格 | Cost: Make it cheaper | 采購與供應(yīng)鏈 ERP，SCM |
| 1980~ | 產(chǎn)品質(zhì)量 | Quality: Make it better | 品管技術(shù) TQM |
| 1990~ | 產(chǎn)品推出速度 | Lead Time: Make it quicker | 產(chǎn)品開發(fā)管理 PLM，PDM |
| 2000~ | 服務(wù)內(nèi)容多樣化 | Service: Offer more | 服務(wù)內(nèi)容與流程 BPM，SOA |
表三：各年代的企業(yè)經(jīng)營管理重心
為了提供多樣化的服務(wù)，許多企業(yè)活動將被解構(gòu)后再重組為新的營運模式，而這代表位居幕后支持的IT技術(shù)，必須能迅速配合這樣的營運模式改變。也就是說，所有的IT技術(shù)與信息系統(tǒng)，都能夠像變形蟲一樣，隨時解構(gòu)后再重組，在短時間內(nèi)提供新營運模式所需的信息服務(wù)，這包括企業(yè)后臺營運所需的信息系統(tǒng)，以及面對客戶所需的前臺服務(wù)界面。
在十倍速的時代，企業(yè)無法等待。常規(guī)為了新營運模式而大規(guī)模更改 (而非重組) 信息系統(tǒng)的方式，過于牛步化無法滿足要求。下一節(jié)提到的SOA架構(gòu)，替服務(wù)導(dǎo)向的企業(yè)，提供了很好的解答。
天生一對的企業(yè)流程管理(BPM)與服務(wù)導(dǎo)向架構(gòu)(SOA)
SOA的IT技術(shù)本質(zhì)單純而不難理解，個別的技術(shù)元素分別理解還算容易。對于SOA，大家聯(lián)想到的就是Web Services，談到Web Services，我們就直接脫口而出：WSDL、UDDI，以及SOAP，然后就是一系列的WS-＊的技術(shù)標準。對很多人來說，只了解個別技術(shù)單元，并無法領(lǐng)會到SOA世界的美好。就好像只看得到調(diào)色盤的每個顏色，卻看不到美麗動人的畫作。所以，讓我們先把無趣的技術(shù)名詞擺一邊，這無助于我們了解SOA的美好世界。
首先，我們需先認識SOA世界里的企業(yè)流程運作方式，以及SOA的技術(shù)元素可以互相彼此串接而形成豐富的生態(tài)；如此，就可知道為什么BPM與SOA是天生一對——SOA 架構(gòu)總存在美妙的答案來滿足BPM變化多端的環(huán)境。
一般來說，真實世界的BPM，具有以下的IT需求特征：
以上五個特征，剛好可用來陪同我們探索SOA的技術(shù)世界。
針對特征一，SOA技術(shù)架構(gòu)可提供安全的網(wǎng)絡(luò)傳輸與運行環(huán)境。主要技術(shù)有二：一是軟件模塊互相通訊時，所需的保密需求，這可由WS-Security來達成。另一個則是組織成員在環(huán)境中的權(quán)限控管方式，這可在SOA架構(gòu)內(nèi)，采用LDAP、集成單一帳號登錄、PKI架構(gòu)與數(shù)位簽章等機制來配合。
第二個特征引發(fā)的議題是SOA工作協(xié)調(diào)與應(yīng)用系統(tǒng)集成。常規(guī)應(yīng)用模塊在SOA的世界里，可以采用SOA規(guī)定的服務(wù)界面(Services Interfaces)對外開放模塊的功能。應(yīng)用模塊之間，透過SOA的服務(wù)界面標準互傳資料，就是最簡單的Web Services應(yīng)用案例。此機制的主要意義在于：所有SOA內(nèi)的應(yīng)用模塊，只要提供SOA的標準服務(wù)界面，就可以不受開發(fā)語言限制，互相調(diào)用或傳遞資料。這里的服務(wù)界面，講的就是WSDL(Web Service Description Language)；而SOAP(Simple Object Access Protocol)則是規(guī)定應(yīng)用模塊之間互相調(diào)用或互傳資料時的封包格式。至于WSDL或SOAP的內(nèi)容與格式應(yīng)該長怎樣，大部分技術(shù)人員可以讓中介軟件或者EAI系統(tǒng)代勞，透過Service Adaptor直接把常規(guī)應(yīng)用模塊包成Web Services模塊，并不需煩惱內(nèi)容的細節(jié)。
第三個特征引發(fā)的議題是SOA的服務(wù)組合彈性與松散耦合（Loosely Couple）的特性。SOA內(nèi)的應(yīng)用模塊若要能輕松改變組合方式，或者改變運行位置，就要藉助SOA的兩個技術(shù)特性：松散耦合，以及UDDI(Universal Description, Discovery, and Integration)機制。因為松散耦合，所以某一模塊抽離或添加系統(tǒng)，并不影響其他模塊；因為有UDDI機制，所以新應(yīng)用模塊添加時，只需跟UDDI服務(wù)器登記新服務(wù)的界面與所在地點，即可被其他應(yīng)用模塊搜尋到，并且開始交互。因為有UDDI，所以當某項應(yīng)用模塊遷離位置，原有使用此應(yīng)用模塊的其他模塊，可以透過UDDI查找服務(wù)的新位置，然后用新位置連結(jié)即可。這種特性滿足「經(jīng)常需要把服務(wù)節(jié)點拆解再重組」的BPM服務(wù)導(dǎo)向經(jīng)營模式。
第四個特征談到的是可管理的SOA Web Services。這是系統(tǒng)管理與軟件管理的議題，雖然當前沒有統(tǒng)一的標準來規(guī)范管理軟件與被管理模塊的行為，但當前稍具知名度的SOA環(huán)境（特別是Application Server）多半會提供系統(tǒng)管理工具給系統(tǒng)管理員使用，協(xié)助管理SOA架構(gòu)下所有列管模塊的安裝、移除、啟動、停用，以及應(yīng)用模塊的狀態(tài)監(jiān)控與安全機制。
第五個特征，談的是SOA技術(shù)架構(gòu)是模塊化又可彈性串接的特性，在原有SOA環(huán)境添加新的技術(shù)模塊，即可漸進式提升BPM技術(shù)的成熟度。我們從ZapThink整理的SOA藍圖中，可以得知達到不同SOA成熟階段所需具備的SOA技術(shù)。舉例來說，假設(shè)SOA有階段實施的計劃，那中間過程可以從「點對點集成」開始，進步到「提供松散耦合的服務(wù)」，再來是「穩(wěn)定而可搜尋發(fā)現(xiàn)的服務(wù)」，接著「提供可組裝與再利用的服務(wù)」，進而達到最終目標——「全公司的SOA」。當然，也可從藍圖中得知，不同SOA階段所能獲得的投資回報(ROI)，剛開始只能是「降低應(yīng)用程序的維護成本，達成點對點的集成」，接著是「透過服務(wù)再利用提升效率」，再來是「提升管理能見度與控制力」，最后才是「改善組織的敏捷度」。
結(jié)語
其實，即使是資深的BPM/SOA規(guī)劃者，想要跟決策主管解釋清楚SOA的博大精深以及其效用，都是很大的挑戰(zhàn)。主要原因在于其中大大小小的技術(shù)條目，以及其相當復(fù)雜的關(guān)聯(lián)。雖然大家都知道，畫出一張易懂的圖解，勝過千言萬語，然而好圖難求，幸好今年(2005)十月ZapThink公司推出一張令人深刻的SOA藍圖海報。這張嘔心瀝血之作，讓人能從各個構(gòu)面、由入門到高級，逐步探索SOA的世界，而且過目難忘，卻又能夠不失BPM/SOA技術(shù)的深度與完整度，實在非常難得，在此推薦這張海報作為延伸閱讀，也當作本文的尾聲。
附注
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，簡單說法：使用流程技術(shù)來描述并控制Web Services的調(diào)用順序，使多個?eb Services依序發(fā)生，運行事先安排的工作順序。?
8. Web Services Choreography，簡單說法：在跨流程的情境中，以Web Services技術(shù)，描述流程個體之間的消息傳遞關(guān)系(多半是網(wǎng)狀結(jié)構(gòu))，以及流程狀態(tài)的控制與查詢方式。?
9. 參閱本文「天生一對的BPM與SOA」小節(jié)?
10. BPDM的目的在于提供可通用于多種流程塑模方法的中介模型(meta-model)，以便不同塑模方法生成的流程定義可以互相轉(zhuǎn)譯。如UML、BPMN，或者其他廠商的專屬表示法，能夠?qū)φ盏酱酥薪槟Ｐ?#xff0c;然后互相轉(zhuǎn)譯；或者讓流程定義轉(zhuǎn)譯成底層的可運行格式，如BPEL原始碼，乃至于J2EE或 .NET的運行碼。 R. Schmelzer and J. Bloomberg, ZapThink's Service-Oriented Architecture Roadmap, URL: http://www.zapthink.com/report.html?id=ZTS-GI103
本文原刊載于：iThome企業(yè)軟件技術(shù)應(yīng)用專刊（2005年）
作者：華苓科技副總經(jīng)理 楊基載
總結(jié)
以上是生活随笔為你收集整理的BPM那些事儿——BPM与SOA的演进与展望的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 各种表
- 下一篇： 如何申请并使用 eepromARMtoo