Executable BPMN for Business Analysts?

People asking for the differences between BPMN and BPEL they often hear BPMN is graph oriented whereas BPEL is block oriented. But what does that actually mean and why is it important?

Block orientation means that there is no way back in the process like a goto statement. In BPEL a common workaround is to use loops to move backwards in a process. But this approach is cumbersome and creates non intuitive models. Block orientation feels natural for developers as it is how programming languages such as Java or C# work.

For business people this feels odd, cause it is not how they perceive processes in their daily business.
Business people regularly need a way to say “Oh wait, there is a problem in step X, let’s go back to step A and fix it.”.

Graph orientation means that the process can flow between tasks even backwards. In terms of Business/IT aligment graph orientation is a clear advantage as it is closer to how people think and work.

Because BPMN is graph oriented it is way better suited for business analysts than BPEL. Does that mean that with BPMN business people can create executable processes? In theory yes! And in reality?

As long as the BPMN model is purely prescriptive, people can freely connect tasks in all directions (more or less). But if the aim is to create executable process models, the BPMN semantics come into play. Although your modeling tool might allow to create all kind of links, process engines are very strict in what they can do. An executable model is like source code and as such follows strict rules.

Let’s create a simple example:

For an analyst this might look like a perfectly modeled process. The problem is that it ignores the BPMN semantics. Neither the modeling tool (Signavio) nor the process engine (Activity) complains, but at runtime the process runs into a deadlock situation. Why that?
The parallel gateway used to join the process after the execution of Task 1 and Task 2 expects two tokens. On the first run it gets two tokens and everyting is fine. If the completed gateway continues with Task 2 on the second run, the joining gateway receives only one token and the process is on hold cause the second token never arrives.

If the aim is process automation, it is essential that the process strictly adheres to the BPMN semantics.
For most business oriented people (at least the ones that I know) this is new completely new terrain.

Goto is not Evil

Those of you who tried to convert BPMN to BPEL know the “Goto”-Problem which stems from the fact that BPMN is graph oriented while BPEL is block oriented.
This makes it hard to transform one into the other and causes pain in todays BPMN undertakings.
Although goto is banned in modern programming languages, business-like modeling languages definitely need it.
The upcoming version of Windows Workflow Foundation with its Flowchart support gives a good example how this could look like.
In his blog Maurice De Beijer has a nice image how this looks like in the Visual Studio.NET Workflow Designer.

Free BPEL 2.0 Designer

Active Endpoints, Inc., the leading provider of SOA orchestration products and services, today announced the availability of ActiveBPEL 3.0. The ActiveBPEL product family includes open source and commercial SOA orchestration solutions that are standards-compliant and platform-neutral, forming the foundation for fast, cost-effective business and systems integration. Among other important capabilities, ActiveBPEL 3.0 comprehensively supports the forthcoming WS-BPEL 2.0 standard, which will be officially published early in 2007.
The Eclipse based ActiveBPEL Designer is free.

Mediation and Orchestration

If you are in a real project knowing the difference between mediation and orchestration is important.
In my previous blog entry I gave a short introduction into the different types of processes.
If found some interesting articles that provide more detailed information about the subject.

A good article written by Satadru Roy about mediation and orchestration can be found at
SOA infrastructure: Mediation and orchestration

Another one written by Ronan Bradley is:
ESB: saving SOA from a dead end

Platform Independent BPEL Designer

For good reason a lot of people are claiming a contract first approach in terms of Web Service design.
I think it makes perfect sense to use a sound vendor independent format to describe important resources like for instance Web Service interfaces.
But this approach is not limited to WSDL only. It applies to Business Process Execution Language (BPEL) as well as business processes are very valuable resources for every company. So if you have to model bunsiness processes for technologies like Microsoft Biztalk Server 2004 or BEA Weblogic Integration you might be good advised to use a BPEL first approach. Two tools that might help you are: Oracle BPEL Designer and
Cape Clear Orchestrator Beta. Both are Eclipse plug-ins and create plain BPEL 1.1 which in turn can be imported to the application of your choice.