Wednesday, 20 June 2007

Is BPMN The Solution For All Process Languages ?

I would like to start this freely available answer with "It depends...", the typical answer of expensive consultants :)

BPMN is clearly a great language for non tech analysts. But the approach that BPMN has to map BPMN to all the executable process languages is sometimes misinterpreted. The Process Virtual Machine describes how multiple process languages can be supported by one single runtime engine.

The text below started off as an explanation of how we can replicate that approach in a graphical process designer. But it also contains a no-so-traditional-but-nonetheless-realistic view on how business analysts and developers can jointly work together on the automation of business processes.

A component model for nodes
On the tooling end, the base framework should be able to display nodes and transitions. Like e.g. in BPMN, but ignore the decorations and the properties for a minute.

Then a process construct should be a plugin. The plugin contributes the following to the base plugin:

- shape: the tool could predefine the 4 BPMN shapes, but a node-plugin should be able to self-define it's shape with its own figure.

- configuration: the plugin should contribute a properties form to enter the configuration information for that node type. to enable this, the internal model of the process graph must have a dynamic set of properties.

- constraints: the plugin should be able to specify constraints like: this type of node can only have 1 outgoing transition. or: outgoing transitions from this node type can only be connected with node type z.

- decorations: which decorations are supported. maybe this could be done with icons so that apart from the BPMN decorations, node implementors can supply a graphical colourful icon.

The whole idea is that you should separate all the node type specifics from the basic process designer container.

Guidance for process languages
BPMN recognizes multiple process languages. But it has suggested a problematic approach to handle that.

BPMN defines a mechanism of bidirectional mappings from BPMN to executable process languages. This suggests that you could model in BPMN and then translate to any executable language. IMO, that is a unidirectional translation.

When an (non-tech) analyst starts to model a process, this has to be done in free modelling language like BPMN, visio or IDS Scheer's ARIS notation. Of course, those models only contain graphical information intended for human-to-human communication and they are not executable.

Executable processes exists of graphical structure and technical details to make a process executable. The graphical picture is the common language between analysts and developers. An executable process is human to system communication in the sense that it specifies to the computer system what it has to do.

The translation from a modelling process (graph only) to an executable process (graph and tech details) is a big one. First of all, the analyst may have modelled steps in the model that are not to be automated by the computer system. Second, the developer makes a selection as to which process language best fits his technical environment. It will most likely not be possible to keep the original process model as-is for the executable process because of the executable language specific constraints.

After the translation to an executable process, analyst and developers have a common language in the graphical part of the executable process. But now, the analyst lost his freedom to change anything he wants since that implies software changes.

This is why I come to the following conclusion: A process designer tool should support each process language individually. BPMN is one of those languages/notation. This is the free modelling tool. Then BPMN diagram can be converted (1 time translation) to executable process languages like BPEL, XPDL and jPDL. This translation should generate a new file.

For modelling an XPDL process for instance, the designer tool should present itself as a straight XPDL editor. All the parts that XPDL specifies should be exposed by the tool with their proper names (properties and node types). But where XPDL is undefined (like in the graphical notation), that is where BPMN can be used to complement. Same story for other executable process languages.


  1. We are looking into extending the Oryx editor to support JPDL since our XForms+JBPM platform uses that and I've been looking for the offical recommendation of Jboss on this. JPDL is excellent although the Eclipse editor is pretty limited (not showing graphically for example the actors/pools). Oryx already seems to have a BPMN editor so I was wondering if we should switch to that or not, but it seems you are saying that it isn't a runtime process language and needs to be ported always? What is the official jboss jbpm teams view on this?

  2. This certainly has our interest.

    I've started a topic on our development forum. Your particiation is appreciated.

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

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

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

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