我們在業務流程管理（BPM）領域里摸爬滾打已經很多年了，最近看到人們對它的關注不斷提升，這是非常有趣的一件事。對這一趣事兒起催化作用方面的有，工具的日漸成熟、新BPMN2.0規范的形成、以及更多更好的相關出版物帶來的人們對BPM的進一步理解，它們代表著BPM領域內最重要的進步。

　　廠商提供了越來越高精良的圖形化工具以及由其承諾的業務流程實現自動化，無需任何編碼甚至開發者參與；然而，我們也發現了使用這些“傳統”的以廠商為中心方法的一個問題：它們并未履行任何承諾！

　　我們以前的一些項目可以佐證以上觀點。公平起見，既然這些工具大都會面臨相同的基本問題，就不具體點名是什么工具了，有個同事不得不使用一個小的Web界面工具來實現一個簡單的流程。這個工具提供了一個特有的、神奇的可拖放界面設計器，剛開始用似乎還比較方便，但當我們項目快要結束時，出現了一些需要對表單上的數據進行細微校驗的需求，而這個“神奇的”工具并不提供該功能。為了規避這些局限性，我們花了比使用簡單的JSF實現整個界面更多的時間去搞這個設計器，不管怎樣，我們最后還是搞定了。

　　在另外一個客戶那里，某個開發者曾告訴我說，“他花了兩天多時間嘗試對一些特殊需求進行建模，而他本可以用Java在半小時內直接實現的！”還有一個客戶嘗試運行交易服務和有狀態服務，而這不幸需要以Web服務方式調用服務。在使用WS-Addressing，WS-AtomicTransaction等標準進行實驗并試圖拼接一些框架之后，基本上他放棄了整套BPM工具。

　　而下一個客戶在競標初期就將廠商踢出了局，因為他們需要更多的資金以便自己提供一套Java API。

　　所有這些例子有一個共同點：工具使得開發者的工作更困難而非更簡單！這些工具沒有減少開發所需的時間和金錢。它們對使得業務和IT相契合并沒有提供進一步的幫助，這是因為所需的技術模型非常復雜以至于不能和業務流程模型完全相一致。你有看過BPEL模型（所制作的流程圖）和業務人員最初所畫的流程圖有任何共同之處的嗎？

　　那么，BPM不起作用嗎？難道業務和IT契合始終是一個神話？當然不是！話雖如此，我們卻不得不反思我們做BPM項目的方式。經過過去幾年的不斷反思，我們找到了BPM在真實項目中的運作之道。

　　簡單說來，BPM更多地關注流程的協作以及充分考慮協作過程中參與的不同角色，并使人們按照他們期望的方式工作。因此，它不太以工具為中心，因為就算我們需要用工具，也應該是工具來適應我們的工作方式。我們必須結束那種工具強迫我們按照廠商規定的方式來工作的情況。不同的角色使用不同的工具，所以不存在獨一無二的工具。雖然這看起來顯而易見，但許多工具還是試圖與此背道而馳。

　　為了能夠使得業務和IT相契合，我們開發了一種使用BPMN（業務流程建模和標記）的方法論。它以流程模型為中心實現協作，我們可以進行討論并將需求、業務規則或其他物件連接起來、使開發狀態形象化、使業務驅動的測試場景得以細致明確等等。它不僅僅可以對可執行的流程進行建模，而且還對周邊“池”中的各組織的視角進行建模，以使業務和IT視圖相契合。

　　因此，BPMN提供了一種很大的可能性：“池”。“池”的使用為用同一種模型來構建“業務特有的”和技術的兩個方面，并為設置二者間的正確的關系提供了可能。在我們的書中對此進行了詳細的描述，并且在官方BPMN樣例文檔中提供了一個例子。你也可以通過我同事寫的一篇博文弄明白我現在所表達的意思。總之，我們把那些看作BPM的真正價值，而不是業務人員“描畫”可執行的流程。

　　我們已經在一些客戶那里實踐過這種方法，有些客戶甚至還在使用Microsoft Visio工具。當然了，在過去幾個月里，我們也開發了工具在幾個試點客戶那印證這種方法，其中最重要的一個大項目是為一家大型德國電信公司做的。目前，我們以通過camunda fox開源項目發布所有資料，其第一版本將很快會公之于眾。我們希望分享我們的經驗，通過討論吸收新觀點，并幫助BPMN規范以得以正確采用。那樣它就會為每個人創造真正的價值，而不僅僅是為那些工具廠商的銀行賬戶增值;-)，如果順利的話，我們可以跳過Gartner的技術成熟度曲線理論中所謂的“幻滅期”，尤其針對BPMN 2.0而言。

　　讓我們更具體一點看看我剛剛提到的那個電信客戶項目。當時我們所面臨的環境僅僅是使用了許多EJB、一些JMS以及有限數量的JBoss ESB服務的Java EE。流程還沒有進行統一文檔化，業務部門大多采用事件驅動流程鏈（EPC）的方式，而IT人員盡一切所能使用了UML、Power Point等等。我們的目標是針對業務和IT，通過引入BPMN作為建模標記，使其成為保持模型的技術化和業務流程同步的橋梁。

　　我們最終達到了我們的目標！但當時是舉步維艱，必須按部就班……

　　技術上講，一個“超級棒”的JBoss SOA平臺啟用，這意味著可以部署可執行流程已到JBoss jBPM 3.2這一著名的開源流程引擎上。我們在幾次不成功的嘗試使用BPEL（其實并不適合技術環境）后做出了使用jBPM的決定。主要的原因根本在于那些服務不能作為Web Services來用，工具也不足夠成熟，價格太昂貴并且也缺乏技術訣竅。因此，jBPM是一個不錯的選擇，它可以讓現有的Java開發人員很快上手使用，并且對開發過程的影響也非常之小。在此我要特別要指出非常重要的一點：類似JBoss jBPM或者不久前的Activiti ，這樣的開源流程引擎對開發人員來說更像是某種框架或庫，而不是一個完整的產品套件。它們可以容易實現客戶化定制并集成到你自己的架構中。它們支持單元測試，理解起來也很容易。

　　記住：我們希望給不同的角色提供其所需的工具。開發人員樂于接受Java、Eclipse、JUnit、Subversion、Maven等工具。因此他們應該能夠繼續使用這些工具！

　　業務分析人員有一個商業化工具Signavio edition 在手，這是這些業務人員樂于使用的工具。而開發人員并不一定要使用它，因為訪問存儲模型的方式是多種多樣的，你可以任意選擇。

　　問題是：“如果我們用不同的工具而它們使用不同的存儲庫，那么如何才能使這些（工具產生的）模型同步呢？”解決辦法也很簡單：我們在不同的工具和存儲庫之間創建了一個粘合“層”。這一粘合包含了一個簡單web應用，它能夠訪問存儲流程模型的Signavio存儲庫和存儲技術工件的SVN的。基于工件的不同類型，我們做不同的特殊處理。比如從Signavio BPMN模型生成jBPM模型。這種粘合層已經成為了camunda fox的一部分，下面將對此展開具體討論。

　　保持業務流程模型和技術流程模型一致是非常重要的，因為這是保持流程模型版本最新的唯一方法。這極其重要，不僅僅出于歸檔目的，也是為了在業務流程模型一級報告KPI（關鍵性能指標）或類似指標。當然，我們可以使用相對容易的粘合層達到該目標，而無需所謂的高度精良的零代碼工具。

　　為了說明粘合層怎樣發揮作用，我會列舉幾個截屏來演示。試想某個業務分析師創建了一個業務流程模型，并且已經完成了第一次迭代。他想要將其遞交給IT團隊以便實現該流程。他通知了技術項目頭頭告訴他可以開始工作了，這只需通過電子郵件發送一個鏈接就可以輕松搞定。好了，那現在該項目的頭兒有活兒可干了，他需要對BPMN模型做一個操作以便在SVN中創建一個開發項目。這一操作可以通過項目模板來完成，而此模板是由一個從BPMN模型所創建的jBPM流程定義來生成的。我們通過一種自己實現的“特殊的映射”來實現該模板。所涉及的基礎映射可以延展到全公司、整個部門、甚至是某個具體項目的規范和模式。即便是BPMN 2.0，使用映射也是有意義的，在我的博客中你也許能找到其中的原因。

　　接下來，開發人員開始工作，完成所有那些另人繁瑣的技術細節，在流程中加入所謂的ActionHandlers，它在流程運行的整個過程中負責執行Java代碼。這感覺基本上和其他Java開發項目沒什么區別了。

　　流程沒有必要一定要部署到SOA平臺才能測試，正常的JUnit測試、持續集成等等都可以。總之，常規的Java和jBPM開發都沒問題。

　　你可能已經猜到Signavio和jBPM模型之間的連接在后臺保存。所以一旦開發者有更改行為，我們就可以在camunda fox（web應用）中看到。并不是所有更改所引起的變化都應該合并在BPMN模型中，所以開發人員需要向業務分析人員發送郵件或安排一個切實的會議進行通知。他們可以使用fox GUI來發現簡單的區別并將這些更改復制回Signavio存儲庫中。

　　事實證明那種方法很奏效。在項目最后，我們所使用的描述性的BPMN圖和可執行jBPM流程實現了同步。而大家喜歡它的原因各不相同：BPMN在業務部門得到認可，而這種及時更新的流程描述確實大受歡迎。這種輕量級的開源流程引擎在開發過程中很實用，并且對Java開發人員來說很直觀，我認為這是極為重要的一點。正是兩者之間的粘合增加了原本缺乏的關聯。與此同時，我們在另一個客戶的不同項目中也嘗試了該方法，并且結果證明同樣非常有效。但是請記住這種方法只是個樣例；如果你嘗試不同的做法，盡管去嘗試——使用適合的工具來配合你的需求！

　　接下來，我們盡力爭取另一個“唾手可得”的碩果。因為在不同的模型和粘合層之間有了一個鏈接，我們就可以有一個中心入口點去提供流程的概貌。我們可以得知有哪些流程版本，哪個版本發布在業務端，哪個BPMN版本作為jBPM流程來部署到引擎，以及在引擎上并行運行著哪些不同的版本等等。

　　就算在引擎上，也可能存在不同版本的流程同時運行。這些鏈接也可以顯示一些用來測量運行在jBPM引擎上的流程在BPMN級別的KPI。如下圖所示。

　　坦白地講，我們在這兒所做的只是冰山一角！將此作為出發點，有無限的可能對粘合層進行擴展。一個有趣的方向是對分布式團隊（比如離岸外包項目）進行支持。這種情況下你需要更多的交互功能。這些功能包括比如討論流程模型并歸檔關聯的討論郵件。這離構建一個通用訪問點訪問存儲庫和工件，能夠讓它們互相標示、連接或與流程模型連接起來的想法只有一步之遙。這使得以Word文檔記錄的項目訂單實現可追蹤性，并且可以在網絡硬盤上保存BPMN圖形和技術模型。目前我們正在開發一些不同類型的標示和虛擬文檔以期提高客戶體驗和整體感覺。你可以通過查詢Activiti Cycle Vision繼續了解這方面類似的發展方向。

　　一個更有趣的方向，也是我們想要在接下來的客戶項目中攻克的是提供更好的流程測試支持，這在我的博文中有所描述。還記得我提到過我們目前正在做的一個數據流原型嗎？它能夠動態顯示被處理數據的數據流，該數據在BPMN級別上依附于流程的Java類中使用或產生。

　　這種數據流原型會特別便于使用，如果你要實現“只需”調用服務的高度自動化流程，你會花大量時間糾結于這么一個問題：“我需要哪個數據，而這個數據是由誰在何處創建的？”最后，也是最重要的是，我覺得將流程和規則相結合具有巨大的潛力。不是什么新鮮事兒是吧？開放的粘合層使得你很容易地在業務級別通過決策表來創建規則，并且把規則和BPMN流程模型關聯起來。在可執行流程中，這歸結為Java代碼的一小部分，比如說，JBoss Drools，一個絕妙的開源規則引擎。雖然一些大的廠商已經提供了類似的東西，但是我們的方法也將會把這一功能引入到開源世界中。

　　希望我已經描述清楚了如何使得業務流程模型和技術流程模型同步這一想法。我想要概括的是有一種實用的方式創建一些簡單的工具來支持你所需要的方法。此外，既然它是開源的，并且具有可擴展性，那么你就可以利用它來實現你自己的想法，擴展它以滿足你的需要。我們已經有了使用這種方法的良好經驗，而我們也將會繼續開發camunda fox，在未來不斷的試點項目中與客戶攜手一起努力。

　　當然，camunda fox也不是什么靈丹妙藥 ;-)但是如果你的項目里用到了（Java）開發，那我認為值得你花時間去嘗試使用camunda fox并給我們提供反饋意見！我們每天還在學習很多新東西，而我很好奇我們最終會在哪里停步。我堅信，不管怎樣，我們投入的所有精力終將會得到一個截然不同的方法用以開發以流程為中心的應用。好消息是：我認為這對大家都有好處。

　　【英文出處】：A collaborative approach for real-world BPM