Tuesday, 4 December 2007

BPM Arrives Into Puberty

Bruce Silver is in a real interesting discussion with Marlon Dumas. They are discussing how to synchronize the analysis model of a business process with the executable implementation of a business process.

In my opinion, most BPM Suite products are still in childhood or kindergarten, even when they may have many bells and whistles. The root cause is that most BPM products still pursue the goal of letting non technical business create executable software. The idea is that with a graphical tool, non technical business analists can graphical design a process that is executable on a BPM System. <synical>In general, it's simply not a good idea to put software, produced by a non-technical person into production.</synical> The more realistic goal is that BPM tools try to improve the communication between non technical business analyst and developers and support the development cycle of that type of software.

I have been saying for a long time that analysis and implementation cannot be unified. So it's nice to see that leading industry experts like Bruce and Marlon are coming to the same conclusions. Although they still have different ideas about the implementation parts of the equation, at least, we all seem to be acknowledging the necessary separation between analysis models and executable models of business processes:
"No one is talking about removing IT from the BPM lifecycle. In fact I even agree with your 3 roles, although I would describe their function slightly differently. The business analyst creates process models in BPMN. The solution architect (IT) makes model activities and gateways executable by configuring them via point-click dialogs and wizards (no code). The developer creates business services using Java, BPEL or whatever, which can also be bound to model activities to make them executable. The developer may be working in the SOA tool, while the business analyst and solution architect are using the BPMS."
The part where I see different is the conversions between the analysis model and the executable developer model. After an analysis model is translated into an executable process, there should be only 1 single executable process. That executable process can still be seen by the non technical people in read only mode. Consider this a projection, where the non technical view hides the the implementation details like transaction demarcations and only shows the graphical part and the business level properties and textual descriptions.

I don't think that roundtripping between the analysis model in BPMN and the executable model BPEL is feasible. It would be similar to maintaining a separate UML class diagram for the analysis of a domain model and for the implementation model. That is in practice simply not done. In my opinion, the goal should be that the executable process languages impose the least possible restrictions to make an analysis model executable.

That is the problem of using BPEL for BPM. People have started to realize that BPEL didn't deliver on all its promises. When its used as a service orchestration language to script new services as a function of other services, I didn't hear many complaints yet. But when BPEL was used for Business Process Management, that's when I heard a lot of complaints. It imposes too many restrictions and hence it's hard for an analyst that produced an BPMN analysis model to recognize the process after it has been translated to BPEL. Other languages like jPDL and XPDL are much better suited to make analysis processes executable without touching the graphical view. For one because those languages are graph based. And in the case of jPDL, an extra capability is Actions, which allow developers to add pieces of programming logic to the execution of a process without changing the diagram.

So when we (the BPM industry) would abandon the goal to let the analysts create executable software and acknowledge that, even in BPM, analysis models are different from executable implementations, then it would be a clear sign that we're moving from childhood into puberty :-)

If I recall correctly from this presentation, Neal Ford made a similar comment in general about Domain Specific Languages at his keynote in TSS Barcelona. The idea was that DSL's are there to create languages that make sense to non technical people.


  1. I completely agree with the idea that the value of BPMS, or BRMS for that matter, is in the increased collaboration of business and IT folks. The rules business has been working on this for a while with graphical metaphors, templates and more - check out this wiki entry. The BPM industry needs, perhaps, to catch up....
    James Taylor
    The Smart (Enough) Systems blog
    My ebizQ blog
    Author of Smart (Enough) Systems

  2. James,

    If decision tables in a spreadsheet is what you mean with templates for rules, then I see a big similarity with how we approach the process languages.

    Decision tables can be seen as a DSL on top of a general purpose rules language/engine. That kind of language is minimal, with less complexity, less functionality and less chance of getting it wrong. That way, you can offer an executable language to business users.

    The same goes for our multi process language strategy. On top of our Process Virtual Machine, we support general purpose process languages like BPEL and jPDL. But we can also support more limited languages like e.g. a language to define approval flows in a document management system. If you take a limited amount of functionality (only approvals) and you can make enough assumptions on the environment (a specific document management system) then you can create an executable language that is easy enough for business people to understand.

    The downside of that approach is that you will have a bunch of those DSL's. So the overall complexity remains the same as a general purpose language. But in many situations this is a viable strategy. We envision this in the next generation of jBPM, where it will be peanuts to develop such a custom, limited process language.

    So we see the "process development process" as described in the blog, the way to go if you're using a general purpose process language. And if you're using more dedicated languages (aka your templates), you can get to a situation where business people can actually create executable artifacts.

  3. Hello. This post is likeable, and your blog is very interesting, congratulations :-). I will add in my blogroll =). If possible gives a last there on my site, it is about the CresceNet, I hope you enjoy. The address is http://www.provedorcrescenet.com . A hug.

  4. 1
    秋天賞楓何處去酒店經紀,安排韓國旅遊有獨到心得的寶馬旅行社表示 酒店打工,秋遊韓國的重點就是美食、溫泉、還有雪嶽山美麗秋景。位於江原道 酒店兼差束草、襄陽、麟蹄一帶的雪嶽山,是韓國最早楓葉轉紅的地方,也由於雪嶽山一年四季都有奇岩絕璧 酒店兼職
    、溪谷瀑布等美景,吸引了許多觀光客前來旅遊。一到 酒店工作秋天,以雪嶽山的最高峰~大青峰(1,708公尺)為首,雪嶽山各主要登山路線沿途的楓葉把山染 酒店上班成一片紅色的圖畫,美不勝收。

    標榜「全程無自費」,相當受旅客歡 寒假打工迎,而且價格相當平易近人,只要14500元即可成行。另外還有全程五星酒店、海陸空版的「戀戀秋濟^海陸空濟州4日」 暑假打工,同樣獨家全程無自費!緊張刺激360度噴射快艇(價值韓幣25000元)、飛天熱氣球(價值韓幣25000元) 酒店PT、海水溫泉汗蒸幕(價值韓幣8000元) 禮服酒店等,海、陸、空讓您玩的盡興也只要13900元!現在就去體驗韓國秋天的美景吧~

    驚險摩托車秀HAPPY TOWN 兼差價值韓幣12000元):表演者以機車為主,靈活的玩弄, 打工全世界只有兩組特技人員能做的高難度表演,在一個小時的演出中還有空中飛人﹑民俗雜技和大車輪 台北酒店經紀等表演,保證讓您大呼過隱,不虛此行喝花酒 特技令人嘖嘖稱奇。而享譽全球的國寶級亂打秀(價值韓幣45000元),是韓國人獨創的敲擊樂表演,故事的場景是發生在廚房中,因此所謂的樂器就是就地以鍋碗等廚房交際應酬 用具敲 打出澎湃的節奏。在沒有冷場的過程裡,不需要語言您就可以清楚知道劇情粉味的發展,台上演員還會與台下觀眾互動演出,整場歡笑不斷。

    去過的旅客都津津樂道的酒店喝酒韓文化生活體驗營」,讓您親手體驗泡菜製作,穿著傳統韓服更能體驗韓國婦女的優雅!另外,精緻好吃的韓國美食當然也不能 酒店不嚐:鮑魚太極人蔘雞、長壽麵、、黑毛豬烤肉、還有獨家特色餐「?花魚定食+五花肉+鐵板馬肉+?料」「生猛海鮮大餐」等等讓人食指大動。酒店經紀酒店經紀酒店兼差酒店打工酒店上班酒店經紀酒店小姐酒店打工酒店兼差 酒店工作> 彩妝指甲彩繪口紅彩妝馬甲美白