BPM is not Software Engineering

I agree with Keith Swenson that BPM is not Software Engineering
However, I think that some of the arguments are a little broad. Ultimately we need to have software construction and business process design working toward the same set of goals in an organisation.

Because business people do not have time to learn how to be a Software Engineer, a BPM system need to provide a representation of the process which is meaningful to a business person. It will have the aspects of the system that are important to them, and consequently it may not have some things that a Software Engineer would like. The diagram must not be cluttered by aspects which are “implementation oriented” as opposed to business oriented.

That is reasonable and familiar to anyone who has gone through the tortuous process of delivering software to meet a business need that is crystal clear in the head of the business person at the sharp end but leaves a whole lot of stuff for the developer to make up. Too often, the business requirements whether in a BPMN diagram or good old fashioned English paragraphs are missing simple things like what happens when the process does not work (business-wise rather than software crash).

Once a business person draws a diagram, that is the diagram that is executed. It must not be transformed to a different form for the convenience of the Software Engineer.

This sounds good as well and is often used to rubbish the use of an established form of software solution as a means of delivery for the new method of expressing the business problem ... "Can't use BPEL because it does not look like BPMN" . This misses one good reason for using transformations or compilations of one logical specification into another, progressively until we end up with instructions for the hardware ... at each level of transformation considerable work has been done to ensure that the forms of expressions are formally correct.
In practice, I think it is sufficient for the business person to draw the diagram defining the process and for all the elements of the diagram to be visible in the execution regardless of transform. So if you freeze the action of an execution, the business person would be able to see that there are instances of processes in play; the current state of any instance can be related to the processing state of activities etc.

The history and analytic reports need to match the original diagram to support the business user in evaluating the performance of the organization, not for the programmer to tell how well the program is running.

Exactly!

By attempting to include all the Software Engineering features in with the BPM (business person) features, the result can be something that is not useful for either. You have people today still believing that BPEL is the ultimate way to implement business processes. BPEL only provides a way to send, receive, and transform — these are Software Engineering requirements, not business requirements. A Software Engineer will tell you that with these primitives you can implement anything, probably even a spreadsheet, but that misses the whole point about why we have spreadsheets and BPM in the first place: because they are not Software Engineering.

While BPEL is not the most capable of languages it does have the merit of having a clear specification of how it should execute. In the same way as a spreadsheet program can be seen as a presentation or interaction layer for a particular class of user connected to a backend computational engine which is tried and tested, a business process diagramming tool with a BPMN or similar presentation form can be implemented through connection to a tried and tested executable engine. If that can be BPEL, who cares?

The problem really arises when the software engineer escapes from the cubical and starts expressing the business process requirements in BPEL and then translating that into a subset of BPMN (for example, with no backward flows) because it can be done.

It really is not helpful to end up with the business process definitions being done in the closed world of "IT" because only they could possibly understand the limitations and technicalities of the "system".

Business process designers (who should not be a specialist breed) need to be able to express the activities, flows, events and decisions of a business process in a way that makes sense to them and the proverbial man on the Clapham omnibus . This means that backward flows, arbitrary cycles, synchronising activities across the process all need to be allowed.

If a software specialist following extensive training and principles in the dark arts of software engineering can create executable code from this business process diagram, then it will be a small step to create software that replaces the software engineer in the development process. At present, in the BPMN/BPEL debate the proponents of BPEL as an intermediate step between BPMN and execution seem short of the patterns that demonstrate that everything that can be expressed in BPMN can be executed in BPEL. Similarly, the proponents of directly executable BPMN are short of the formal definition of the execution rules associated with BPMN patterns.

Executable BPMN via BPEL

In a short burst of discussion about whether BPEL was a viable execution mechanism for BPMN, Keith Swenson provided an excellent example of a valid BPMN expression that could not be expressed directly in BPEL with a follow up in his blog showing that the BPMN could be directly executed using his product.

This was followed up by a spirited exchange between factions with assertions that BPEL could indeed express the business process but no definitive BPEL as far as I can tell. Alex Boisvert acknowledged a bug in the BPEL produced by Intalio Designer v5.2 but unfortunately did not describe the code that should have been produced. [[Update:ActiveVOS provides an answer in its tutorial material ]]

However, the BPMN 1.1 specification provides a couple of items for thinking around this problem.

The use of a new signal element to provide synchronisation behaviour across processes covers exactly the intent of Keith's example.

There may be situations within a Process where the flow is affected by or dependent on the activity that occurs in another
Process. These events or conditions can be referred to as milestones. The process model must be able to identify and react
to the milestone.That is, the continuation of a Process may be triggered by Signal Events, which pass the flow between
processes (see Figure 10.48 reproduced below). The type of Workflow Pattern called a Milestone.

In para 10.2.1.11 Avoiding Illegal Models and Unexpected Behavior of the BPMN specification, the authors touch on the root cause of the issue.

The situation where alternative paths cross the implicit boundary of a group of parallel paths can cause an invalid model.

If there is to be a future for BPMN to BPEL, we need an indication of what transformation needs to be done to otherwise valid BPMN to produce the intended executable.

The use of BPMN signal elements suggests that the bright people at Intalio could replace the doubtful synchronisation with whatever mechanism they are going to employ to implement signal intermediate events (not implemented in v5.2!). That is, implement it as though the BPMN looks like this ...

This then gives us a manual work around until the transformation rules can be codified into the product.

Which raises the question ... does the catch event need to be reached before the throw can be effective? Should I draw the BPMN like this? ...