Wednesday 12 March 2008

BPMN Conformance Sets And Unrealistic Ambitions

In the recent BPMN discussion, Bruce clarifies that he also sees a partitioning in BPMN:
"
The SIMPLE conformance set includes task, collapsed subprocess, gateway (exclusive data-based and parallel), None start and end events, pool, lane, data object, text annotation, sequence flow, and association.

The STANDARD conformance set includes task (task type User, Service, Send, Receive); collapsed and expanded subprocess, looping or multi-instance activity, gateway (inclusive, exclusive data-based, exclusive event-based, parallel), start events (None, message, timer), catching intermediate events in sequence flow (timer, message), throwing intermediate events in sequence flow (message), attached intermediate events (timer, message, error), end events (None, error, message, terminate), pool, lane, data object, text annotation, sequence flow (uncontrolled, conditional, default), and association. [Looks like we left out message flow… not sure why.]

The COMPLETE conformance set includes the full BPMN 1.1 spec.
"
This is very close to (and much more concrete then) the levels that I envisioned. That puts our opinions indeed much closer as I initially estimated. Especially if you only look at the modelling perspective, then I totally agree with you, Bruce.

So now, my only disagreement is not with Bruce, but with the picture that the traditional BPMS vendors paint. He describes it like this:
"
And, like Michael, the tool vendors factor into my thinking as well, in particular the BPMS vendors who support BPMN’s model-driven implementation style.
"
IMO, the BPMN model-driven implementation as pursued by most vendors is flawed. They see the executable language as the byte-code behind the BPMN model. Then round tripping is envisioned between the model and the "byte-code". I believe that it is impossible to let the non technical people drive the executable byte code.

Instead, I think it is much more realistic that the analyst delivers an initial analysis model. This model can be in 'the COMPLETE conformance set' as described by Bruce or it can be boxes and arrows on a napkin. Then this serves as the requirements input for the development team. The executable process language should be a selection of the development team. They can select a language that fits their architecture and the environment of the process best.

The clue is that a good executable process language would allow the developers to build a process that exactly looks like the analysts input. That way, the implementation model is structured in the same way as the analysis model. As a result, analyst and developer can speak the same language.

But crucial is that after the translation of an analysis model into an executable process, the responsibility is transferred to the development team. In subsequent iterations, the communication between analysts and developers can happen around the diagram, but it's the developers that should do the updates to the executable process.

With general purpose executable process languages, it's not possible to let the non technical business analyst modify executable software. The exception is in the specific process languages with a specific target and limited scope. For example a language to specify approvals in a document management system. In those cases, the analysts can build fully executable processes.

The round tripping approach that traditional BPMS vendors put forward tries to automate the translation of requirements into software design. That is, IMO, an unrealistic ambition.

2 comments:

  1. Tom,
    I'm glad we are closer. But I am sorry you are still flogging that old strawman about business analysts building executables. Nobody's claiming that, and that's not what it's about. BPMN is just the model, the activity flow in abstract sense. The implementation properties of each activity, event, or gateway are layered on by developers. Not in code, but using the visual tools even those guys like to use. And not stored in BPMN attributes, but in the tool-specific metadata that drives the executable language.
    The key thing is that the model doesn't change when these properties are added, and even if the developer needs to change it, the business analyst retains visibility, because it's still BPMN. Not only more collaborative, but more agile as well.

    Programming diehards laugh it off when Lombardi, Appian, or Savvion does it this way. See if they're still laughing when SAP, Tibco, and BEA do it this way.

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


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


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


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

    ReplyDelete