我們在業務流程管理（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并給我們提供回報意見！我們每天還在學習很多新東西，而我很好奇我們最終會在哪裡停步。我堅信，不管怎樣，我們投入的所有精力終将會得到一個截然不同的方法用以開發以流程為中心的應用。好消息是：我認為這對大家都有好處。