BPMN - Hard to Code???

Bruce Silver continues the valuable discussion on BPMN semantics and challenges a perception that BPMN has vague semantics.
In the example chosen, I agree with Bruce that

• having flows from downstream activities BPMN is not best practice (in that it can lead to misunderstanding by the casual reader who may more be familiar with basic flowcharts)
• there is only one reasonable interpretation of the required execution of the BPMN and therefore it is not an example of "vagueness".

Looking at the definition of the Inclusive Gateway in BPMN 1.2 , I might accept a criticism that it is hard to read in English and may benefit from formalising.

9.5.3.2 Sequence Flow Connections
This section extends the basic Gateway Sequence Flow connection rules as defined in “Common Gateway Sequence Flow Connections” on page 72. See Section 8.4.1, “Sequence Flow Rules,” on page 30 for the entire set of objects and how they may be source or targets of Sequence Flow.

• To define the inclusive nature of this Gateway’s behavior for converging Sequence Flow:

If there are multiple incoming Sequence Flow, one or more of them will be used to continue the flow of the Process. That is,

• Process flow SHALL continue when the signals (Tokens) arrive from all of the incoming Sequence Flow that are expecting a signal based on the upstream structure of the Process (e.g., an upstream Inclusive Decision).

• Some of the incoming Sequence Flow will not have signals and the pattern of which Sequence Flow will have signals may change for different instantiations of the Process.

Note – Incoming Sequence Flow that have a source that is a downstream activity (that is, is part of a loop) will be treated differently than those that have an upstream source. They will be considered as part of a different set of Sequence Flow from those Sequence Flow that have a source that is an upstream activity (my emphasis).

However it is clear from the phrase "... expecting a signal based on the upstream..." and the note in the section above that the inclusive gateway in the example has no (merge) function in the event that a sequence flow from the downstream exclusive gateway is processed. The token from the loop back is the only one that can be 'expected' at the inclusive gateway.

It will only be hard to code, if the developers have started from a point of view that each node (activity or gateway) can be transformed into an executable form (or executed directly) in isolation. The developer must consider the source of the signals (Tokens) and the structure of the process as a whole.

BPM high-wire act

Intalio appears to be eating its own dogfood very publicly, and on a highwire.
I wish Ismael and his team well with this venture as it will demonstrate that armies of strange developer types are not the key to success in getting value from a business process-centric view of solution delivery.

They are working with real business processes and have very quickly demonstrated two completely different approaches to BPM solutions with the same product.

• A Customer Support Process is presented in the early stages of BPMN expression (Level 2??) and is full of clearly recognisable business steps (like 'assign to support team..').
• The Marketting Process allows the process instance to be configured from a basic template at runtime rather than design time and the BPMN diagram is far more abstract. Perhaps there are some real developers around after all!

The template approach allows the business process to be finalised for each instance in a configuration table and should lead to a stable technical implementation without analysing the business process to death. In doing this, some of the benefits of BPM may be lost. If you look at an instance of the Marketting process through a reporting tool you will see that you are at Step N within a loop of Steps but with no real sense of flow. In contrast, looking at a customer support process instance will show where you are, and how you got there. Without wishing to fan the flames of the executable BPMN v BPEL debate, tailoring the pattern at the BPMN level and executing the result, retains the business-level communication of process requirement throughout the lifecycle.

I look forward to seeing the final implementation.

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? ...

Executable BPMN call for action

In BPMI.org Redux Ismael Ghalimi of Intalio calls for participation in a group to sort out a true executable BPMN. The tentatively titled BPMNLab looks to be a good practical approach to the issues.

• What consitututes executable BPMN?
• Are there useful BPMN flow patterns that cannot be translated into WS-BPEL? If so, how are they best dealt with to produce an executable?

After what has been a bit of sniping from the sidelines on my part, I would be happy to be involved in this effort.

The transformation to BPEL approach seems to me pretty sound. Here is a working language definition appropriate for the BPM domain that is capable of withstanding rigorous assurance testing. Why attempt to define another?

A few BPMN constructs may produce really ugly BPEL code, but who cares except for a few developers in Intalio and the like who have to develop the transformation code. The last thing that anyone in the real world should be doing is fiddling with the generated code. I am reminded of a very successful Unisys product LINC which developed totally unreadable and arguably inefficient COBOL code. In years of use, we had no more reason to look at the generated intermediate COBOL than the final machine level code.

Comply with the specification for BPMN

Bruce Silver in BPMN-BPEL in Perspective responds to the same article as I did here and raises the issue of compliance.

OMG could define a compliance spec for BPMN 2.0 - the elements,
attributes, and flow patterns that MUST be supported to claim BPMN
support. They have made some murky noises about it, but I haven’t seen
anything concrete yet. Since IBM and Oracle are driving the bus there,
it would make sense that that subset would have a defined mapping to
BPEL, but it would allow non-BPEL engines to be compliant as well.

That would be a healthy thing for the industry. But I’m not holding my breath.

I may be more used to specifications for computer languages (like FORTRAN, COBOL) than business process but I suggest that the specification for BPMN 2.0 itself should be what vendors comply with and not a separate compliance statement. Compliance statements from vendors will then effectively state what they have not achieved (yet). Purchasers and consultants can then judge whether the level of compliance of a particular product is sufficient for there purpose.

As BPMN is unlikely to stop at 2.0, a really supportive vendor should not only be compliant with the currently approved specification but also support proposals for future versions, so that practitioners can work with the new ideas while they work through the acceptance process of a standard.

Execution is a different issue. A vendor could opt for a BPEL execution engine (as Intalio uses at present) and reflect that decision by flagging bits of the model as not-executable. An organisation working from the compliant BPMN model could than decide on a method for implementation ...

• use a tool that will generate an executable directly from the model, or
  
• hand the model to an IT developer as a requirement specification

I will be looking for solutions in the first category but we must not lose sight of the fact that a vast number of organisations like to keep a developer shop and consultants busy re-inventing processes in Java or whatever language is the flavour of the month.

Even for Intalio, the execution engine could be replaced by something easier to map to BPMN without changing the user view.

To BPEL or not to BPEL

In Why BPEL is not the holy grail for BPM, Pierre Vigneras thoroughly covers the issues of using BPEL as the implementation layer of a business process solution. From the article conclusions ...

• Therefore, we consider BPMN notation as the only currently viable solution for Business Analysts
• Transformation from BPMN to (readable) BPEL is quite hard to implement, and produces --- when correct --- hardly readable code.
• Therefore, we may wonder why BPMN is transformed to BPEL since there
  exist a graph-based standard that maps directly BPMN constructs ---
  namely XPDL v2.0
• Of course, one may claim that XPDL 2.0 lacks some execution specifications that makes him (sic) unsuitable for direct execution.

Although I am generally a fan of Intalio, Pierre provides a good example of the problems they get when BPMN is used as though it is a convenient graphical expression for BPEL. In particular, a real business analyst can express the process in valid BPMN which is then transformed by Intalio into BPEL which bears little relation to the designer's intention. Worse, the Intalio developers have removed valid BPMN constructs from the business analyst, probably because they do not readily fit with the BPEL implementation. To add insult to injury, there is a general impression that if your valid BPMN does not work, you must have designed your process against some mystic best practice rather than expressed real business events and activities.

I am less concerned about the round-trip issue. If the BPMN is transformed by a product into an execution language which then remains untouched by human developer hand why we should care about the readability of that executable code? The answer is that the maturity of product development in BPM does not give users much faith that the generated code will do what we expect.

If we concentrate on developing BPMN into the way of real business analysts express the business processes and assume an automatic transform into a executable, the choice of implementation paths is only of concern to product developers. Out in the real world we can judge their products by the ease with which we can describe the processes that we find (as-is) and design (to-be).