bpmn-miwg/bpmn-miwg-demos — pull request #2 by ldugan (2014-02-04 17:50:46+00:00)
Title: Create Second Interchange Demo Presentation Issues

My Feedback on the 2nd BPMN MIWG Interchange Demo

Here are some points on the upcoming interchange demo that I feel compelled to share with the rest of MIWG. I realize much of what I say below could be more timely (as in said earlier), but my attendance at the call-ins has been spotty for all of the expected reasons. Some of my points below may not come across as intended and/or may seem as slights to those champions who have labored mightily for MIWG and the advancement of interchange, but I can assure all that my aim is only to put into relief the limitations (as I see them) of the current approach to the demo.

Execution Semantics of the Interchange Example:

I stand by what I said on the call: a manual task is just a pass-through of the token in the execution engine, and if capture/release of the token is required as part of the workflow then it is a specialized kind of user task which simply advances the process instance. I’ve looked at the spec, and found the following citations in support of this conclusion (which also appears to apply to the abstract task):
•	On p. 163 (p. 193 in the PDF), next to Fig. 10.18: the manual task is “expected to be performed without the aid of any business process engine or any application”
•	On p. 165 (p. 195 in the PDF): the manual task “is not managed by any business process engine” and “can be considered an unmanaged task as in the sense of that the business process engine does not track the start or completion of such a task” and is “neither executed by or managed by a business process engine” though it can have a performer (per the meta model)
•	On p. 425 (p. 455 in the PDF), in Ch. 13 (on BPMN execution semantics): the manual task and the abstract task are “non-operational” and “may be ignored”
•	On p. 430 (p. 460 in the PDF), still in Ch. 13: these tasks can be completed without actually being executed

So, in order for the model to be “executable” in the sense of a business process engine executing it, the task types need to be changed to task types that are executable, such as user tasks or service tasks. However, this leads to a new set of issues.

Changing the Interchange Example:

The Trouble Ticket Process from the BPMN 2.0 By Example paper is one I’ve studied and used for a long time, believing Falko and Jakob hit upon something quite profound – namely, showing the emergence of a system pool out of a collaboration of otherwise pure business processes. The behaviors of the model were set up to show a collaboration of participants in trouble ticket handling into which the Trouble Ticket System would be introduced to automate the processing of trouble tickets. Information exchanges along message flows into out of the flow nodes in the various pools are not really automated even though they are informational – e.g., the incoming message received by the start message event Receive Customer Problem could be an e-mail, while the incoming and outgoing messages involved in the manual task Get Problem Description is likely a phone conversation or two in follow up between the Key Account Manager and the VIP Customer to clarify the problem behind the opened trouble ticket.

![model example](https://f.cloud.github.com/assets/4049289/2078885/53266464-8dc3-11e3-9244-d335932c4424.png)

Changing the manual tasks to user tasks can be done, but the presence of message flows going into and/or out of user tasks, while technically legal in BPMN, are difficult (if not impossible) to describe from the business process engine’s perspective since those exchanges occur outside its span of control. Alternatively, changing the manual tasks to service tasks requires that interfaces be defined that enable the invocation of the (for example) web services for which the service tasks are abstractions in the model. Similarly, for any re-interpretation of the modeled message events as moments of automation.

All of this involves a level of BPMN XML attribution that we have yet to test (or at least fully test) – and I have not even addressed the use of extensions likely needed to make it all work as was the case in the Berlin demo (Signavio to Camunda). And we already know of one example, with BonitaSoft, where some visualized elements will have to be ignored in pursuit of this result.

In conclusion, my strong belief is that changing task types and re-interpreting the message events is White Rabbit’s hole, and we don’t want to go down there because we don’t know how deep it really is. If the group is intent on showcasing some kind of execution moment, then I would propose that we insert the system pool as was intended in the original example.

![model example with system pool](https://f.cloud.github.com/assets/4049289/2078902/8848512a-8dc3-11e3-8d19-087c0eb9071d.png)

As was the case in the last demo, the execution engine would have to be told or otherwise know that only one pool contains an executable process (i.e., the one labeled Trouble Ticket System). Making this work as an example would be more than labor enough, in my opinion. If the intention is to show multiple execution contexts in the realization of the collaboration, then all of what I just said is much, much more complex to realize – it would be more akin to its own BPMS deployment than a demo.

Why We Shouldn’t Do Execution:

Here is a laundry list of reasons, any one of which is enough (in my opinion) to warrant not testing it out:
•	We are out of time and are relying on contended resources to solve numerous technical issues
•	We have never fully tested the required level of BPMN XML attribution for such interchange
•	Having one execution context was challenging enough, and it leveraged an already extant medium of exchange between modeler (Signavio) and engine (Camunda)
•	There are problems with making the model executable (see my points above)
•	We have only 45 minutes (actually less than that if you allow for some context-setting at the beginning), and we took more than an hour in Berlin, which was generally understood by attendees as a demo largely, blissfully, and almost magically free of the usual demo problems

I strongly urge the group to target the envisioned execution part of the demo for a future third round. Pursuing it now will (in my opinion) sacrifice or place at risk the realization of a number of tactical objectives at the expense of a strategic one that is of dubious value for the attendees at the setting and is quite likely impossible to achieve under current circumstances.

Remembering Why Reston Was Targeted:

In Berlin, as I recall it anyway, the Reston meeting was targeted principally to be able to reach the US market in general and, because of its ability to affect that market, the Federal Government market in particular (which is based in neighboring Washington, DC). The numerous scheduling challenges aside, little has been done to date promote this event through communication channels to which attendees from or engaged in these markets would be paying attention.

Worse still, the stagecraft and content of the demo are not currently of a type and form that effectively targets those markets. Without the presence of tools that are more familiar to the intended audiences and/or carry the gravitas necessary to get their attention, I fear that the reaction to the demo, no matter what its internal merits, will be a collective shrug. And this is not just me…Dennis Wisnosky, one of the 3 OMG luminaries at the Berlin demo and the one cited in the press release, agrees with this.

In the end, the demo must go on with whatever stagecraft and content that it can. I get that. But, with all due respect to the many (largely non-US) vendors, the aims of the demo will not be realized without some US content. Unfortunately, neither Denis nor I could persuade iGrafx, who apparently sees BPMN tool interchange as a consulting opportunity rather than a product differentiator – as I suspect is the case with other US vendors (though they will likely deny this).

I can use an IBM tool that I have (BlueWorks Live), but an Oracle (thinking BPM Process Composer, not JDev) or equivalent vendor would be good. Other tools likely to be recognized by attendees include: ITP Commerce’s modeler, Signavio, Trisotech, BizAgi, and ARIS (and excluding, unfortunately, iGrafix). (Many other modeling tools are too weak in interchange, in my assessment, or have yet to throw their hat in the ring for MIWSG, but are widely used, including NoMagic, Sparx, and IBM’s System Architect.) Otherwise, the US BPM Suite vendors, as a group, tend to be weak on interchange (still using XPDL).

To the extent possible, I implore the group, both collectively and individually, to work to better calibrate the demo for the likely and desired attendees. To that end, I am proposing a simpler, more streamlined demo with at least one US vendor in the mix. Please note that, instead of each step adding stuff, the creation of the various pools could be split up, which would rely on at least one tool to integrate them together, presumably through a copy and paste drill since I don’t think anyone can import into a model without swapping it out (but I could be wrong).

My Suggested Script for the Demo:

![my script a](https://f.cloud.github.com/assets/4049289/2078995/79facc14-8dc4-11e3-9f0e-97ac3e65d324.png)

We could end it there, and call it successful. Or we could have a step (6), which is to import the completed model back to whatever tool did step (2). We cannot go back to BLW because it has no DI support (BLW uses its own auto-layout) and cannot handle multiple pools in a single diagram (though it can support referencing message events across interacting processes as separate models).

If the group wants to do execution, then I suggest the following additional steps, beginning with the insertion of the system pool (ala the intended use of the example model).

![my script b](https://f.cloud.github.com/assets/4049289/2079013/9b3e8c30-8dc4-11e3-866a-453eb7bcf6c8.png)

The innards of the system pool are filled out in the next step, with the message flows moved from the pool boundary to the relevant flow nodes in the executable process. The executable aspects of this process could be automated in a manner that is opaque to the viewers of the demo but convey the successful transfer of execution semantics (like what was done in Berlin).

![my script c](https://f.cloud.github.com/assets/4049289/2079025/bb8c0b48-8dc4-11e3-917b-42934c6fd5aa.png)

Even if there is diagram or semantic cleanup at one or more steps along the way, something like this will convey the realization and future possibilities of model interchange.

Respectfully submitted,

-	Lloyd Dugan