High-Quality Free BPM Book

Thanks to Sandy Kemsley, I found Michael Zur Muehlen has published his very nice e-book online. No registration required so definitely have a look at it. Even though the book seems to be a couple of years old, it includes a thoughtful and still very relevant description of BPM as a discipline and the relation to BPM software technology.

Dublin, Here We Come !

The jBPM Community Day on June 6th is starting to become a real international event with people coming from Belgium, The Netherlands, France, Germany, Italy and Ireland of course.

The program is updated and gives a good idea of what's going to happen. Also a list of hotels and activities is added (thanks, Paul!)

Don't miss it ! Be sure to registration quickly. It is as easy as sending an email to dublin@jbpm.org

BPM != BPEL

It seems to be a very stubbern misunderstanding that I have tried to straighten out many times before. But for those that didn't get it yet, even John Evdemon, co-chair of the BPEL technical committee said already in 2007 that BPM != BPEL and now in the recent BPMN discussion he adds: If you can do something it doesn't mean that you should...

HTH

Buzzwords In Pictures

Sometimes you can find good explanations of tech buzzwords in real life. So far, I found out what Ajax, SOA and backup really means.

If your HTML-over-HTTP-house is on fire, the Ajax hose comes to the rescue.


If your integration stinks like a sewage system, just put a SOA cover on it.


And a backup is even more vital then I ever imagined.

I'll translate for the non-dutch speaking: "Even mother nature provides a back-up" And in the round circle it says : "Test one month for free". Sign me up ! Sign me up !

Big Problems Ahead For BPMN 2.0 ?

Boris Lublinsky posted a good overview on InfoQ about the online discussions around BPMN 2.0 and it reveals IMO a very profound problem in traditional BPM thinking.

One group wants to give the graphical process modelling notation executable semantics. In that case, a BPMN 2.0 diagram would specify exact (and hopefully portable) semantics and it can be executed on a computer system. On the other hand, some people raise concerns about the simplicity in that approach.

This again shows that today the dual nature of BPM is not enough recognized by BPM vendors. BPM tries to make the bridge between non technical business analysts and the implementation of a business process.

A business process analyis can contain a diagram and it expresses how people and systems work together. Such an analysis is targetted at other people so it can include free text and a diagram. It's description of how things work in the real world. Analysis can be done without even automation. An analysis is always an important input to express the requirements for the automation of a business process. Some analysts use very expressive diagram notations, while others just use boxes and arrows. But even in case a lot of details are expressed in the diagram, they are not necessarily expressing runtime execution semantics in the software sense of the word.

In case a business process is automated with a Business Process Management System (BPMS) , an executable process needs to be created. An executable process serves as input to a BPMS, after which it will be able to execute the process. Executing a process by a BPMS means a combination of monitoring progress and performing automated tasks. Executable processes can also be based around a diagram. But in this case, the diagram is a projection of a software artifact. The executable process will in most cases contain technical details outside the scope of the diagram. Whatever way you look at it, an executable process is software.

There are some aspects that cause some fog around this clear picture. In practice, it turns out that the roles are not that clearly separated. In fact, a lot of business analysts have technical knowledge so they already are able to think in terms of what it means to execute the software. Also, there are different levels of process languages. The more a executable process language targets to be general purpose, the more complex it will be and the more technical it will become.

If a diagram notation (like BPMN) wants to be used for both the analysis as well as the executable process diagram, it should limit the number of details that can be expressed. As analysis details don't match with technical details necessary for making the process executable. The more details that are exposed in the graphical notation, the conflicts will arise because of this dual nature of the process diagram.

More and more vendors start to see that the gap between the analysis process and the executable process can not just be eliminated. But still quite a few target round tripping, which means that the analysis model is kept in sync with the executable model. I have seen multiple vendors come out with features that support this. Still I think that is a waiste of time. Building tools that synchronize automagically between the analysis and the executable diagram is too hard. Using those tools effectively will only succeed in environments with a lot of discipline cause changes in the executable process will often require an analyst to incorporate those changes into the analysis diagram. Furthermore, those tools impose too much assumptions on the analysis language and the executable process language. FWIW, such an approach never did fly with UML Class Diagrams, and I don't see how the situation is different for processes. In fact, in case of UML class diagrams, no-one even thought of automagically synchronizing the analysis class model with the executable classes.

Instead, I think it is much more practical to create an executable process language that can build the executable details around a given diagram structure. That way, the executable process diagram will be very similar to the analysis diagram. The better the executable process, the less the diagram will have to change. But a conversion step cannot just be eliminated. Even if the executable process languages was 'perfect' in keeping the same diagram, some parts in the analysis diagram might not even be automated.

Once a business process gets automated, the diagram in the analysis document can be replaced with the executable process diagram. This has as a consequence that the analysis diagram becomes read-only for the analysts once it has been converted to an executable process.

Instead of embracing the dual nature of BPM, the InfoQ post outlines very well how two opposite camps have formed around analysis and implementation. Previously the focus of BPMN was on analysis only. It's much easier to reach consensus in that more limited scope. Now, the big vendors got involved and expressed a clear vision to make BPMN executable. That opens up the whole discussion of the environment. BPEL clearly chose for an ESB environment based on WSDL. But (just to give another example) jPDL is defined in a Java environment. I don't yet see how you can define an executable process language without selecting a concrete environment in which it operates. This is exactly why we support multiple process languages on our Process Virtual Machine.

The way things are moving now, the move towards executability of BPMN is starting to become clear. But looking further in that direction, I can only see quicksand. As indicated above, the vision of making BPMN executable could quickly be dragged down by many technical "details". It will be interesting to see how that is going to play out, but my fear is that it's not gonna be a smooth ride.

One thing puzzles me, though. Why is everyone talking about a new file format for BPMN 2.0, while there is XPDL ? The WfMC guys did a lot of effort to get XPDL synced up with BPMN and they made a lot of noise about it, so it cannot be an oversight. Still everyone seems to be silent about the possibility of using XPDL as the file format. Does anyone know more about the motivations for this silence ?

jBPM Community Day in Dublin On June 6th

The jBPM Community Day in Dublin is a great opportunity to learn more about jBPM, the Process Virtual Machine or JBoss in general. The core jBPM developers and key members of the community will be there in a relaxed atmosphere. It's just friday afternoon on June 6th. There will be some informative sessions, guinness entertainment and plenty of breaks to network and talk to others in the jBPM community. Lunch and evening meal included and it's free ! What more could you want :-)

Click here for more information about this great event.

You can register by simply sending an email to dublin@jbpm.org with your name in it.

I hope to see you all there.

Process Virtual Machine Alpha2 Released

The Process Virtual Machine is a simple Java library for building and executing state machines. It can optionally store process definitions and executions in a relational database. The Process Virtual Machine serves high level BPM as well as low level Java state machines. It serves as a foundation for several process language implementations like jPDL, BPEL, XPDL and Pageflow.

This second release adds a deployer architecture, enterprise bindings and documentation about the persistence of processes. It further improves the stream handling and the job executor.

Check it out !

The Process Virtual Machine Homepage
Documentation
Download

Enjoy and let us know what you think of it.

JavaPolis Refactored To Javoxx

JavaPolis becomes Javoxx

"
New name
New logo
Same Concept : Giving a voice to the Java community
"

Check it out on the JavaPolis website, On the Javoxx website and at Parleys.com

Mark December 8-12 in your calendars, book your flight and hotel and start packing your bags. This is a mandatory excursion for each self respecting Java developer. This is one of the few situations where I'm happy to fulfil my obligations!

In Depth Analysis Of OSS BPM By Jason Woodruff

Jason was able to extract our grand vision perfectly from the bits and pieces that we've published here and there on the forums, articles and website.

Congrats, Jason.

jBPM Nominated For JAX Innovation Awards 2008

Cool! jBPM has been nominated for the JAX Innovation Awards 2008. The Award Ceremony will take place in the course of the JAX Conference on Wednesday, 23 April.

This got me worried about what we're going to do with the prize money *if* we happen to win it. It sparked the idea of a jBPM Event. We could spend the money on flying in people from the community over to our event.

We already selected Dublin as the place to be and probably June 6th as the date. Mark that date in your calendar ! Chances are good that it's going to happen anyway. So we feel like we've won already, regardless of the outcome :-) But still we hope that we win some prize money to bring lots of community people, partners and clients to our event to share experiences and have a good Guinness together.

Let's keep our fingers crossed...

Awsome jBPM Performance Numbers

Couple of weeks ago I saw a great presentation by Joram Barrez of Dolmen called "The Full Stack". Basically he showed how they selected jBPM and SeeWhy and composed it into a full BPM solution. Since I went to the event with not much expectations, this was a pleasant surprise. Things became even more interesting when Joram showed the performance tests they did to see if jBPM would meet their demands. We wanted to do those tests for ages, but never got to it. So big thanks, Joram for sharing them with us !

As you might know process execution in jBPM can happen with or without persistence. These measurements are done *with* persistence, as this is the most common way of how jBPM is used.

He started with the simplest process. That took 2 milliseconds to execute.
Then a processes that grew longer and longer:

Then he verified the effect of simple and complex process concurrency:


Amen.

So even this complex process runs with only 12 ms overhead of jBPM ! Awsome. Even I was surprised :-)

And the last test was a complete realistic process of handling a hospital report. That took 3 milliseconds to execute.


All of this shows that the overhead created by jBPM runtime process management is really small. Doing the statemanagement of such processes yourself will lead to a lot more development time, and in many cases, the performance will not be as optimized as just using jBPM.

This only highlights the performance evaluation part of the talk. I definitely recommend to read his blog post about the full contents of Joram's presentation.

First Release Of The Process Virtual Machine

We've been talking about it for a long time. And we've been working on it for even much longer. And finally, the moment of truth is here. The first alpha release of the Process Virtual Machine can be downloaded. Documentation and Javadocs are also available.

The Process Virtual Machine now also got it's own home page.

This marks an important milestone for the jBPM project. It's the finalization of our approach to support multiple process languages and embeddable BPM.

But don't wait any longer. Go download it and start building your first processes and process activities.

Complete Refresh Of The jBPM Website

JBoss jBPM has a renewed website. A serious update was long time overdue. We took the time to put the soul of the project into the website. Multiple subprojects now are very prominent, highlighting the fact that jBPM supports multiple process languages. An overview section helps people to understand workflow, BPM and how we approach it.

This new site is part of a larger effort to focus more on building the community further out. Previously we already announced the new logo. We now have about 20000 downloads per month, but we won't rest until BPM and workflow is a ubiquitous part of software development.

Special thanks goes to Koen for making it happen.

My Concluding Nuance On BPMN

Before I try to summarize my position, I'll reference all the related blogs in this discussion:

Michael zur Muehlen: How much BPMN do you need?
Bruce Silver: On How Much BPMN Do You Need
Michael zur Muehlen: Who is at fault - the language or the speaker?
Bruce Silver: Michael Elaborates
Me: The Hottest BPMN Process Modelling Debate, BPMN Conformance Sets And Unrealistic Ambitions and The Devil Is In The Technical Details
And overviews from InfoQ and Sandy Kemsley.

After the above and another good discussion at the Dolmen event: Do’s en don’ts van Business Process Management yesterday, I would like to give another shot at summarizing my point of view around BPMN and indicate where I see most misunderstandings around analysis to implementation.

BPMN can be used for analysis. In that sense, the BPMN analysis model is a model or a description of the real world. BPMN can also be used to represent executable process languages. But in that case the BPMN diagram represents a piece of software.

So my point is that, in general, it is impossible for an analysis model to automagically be translated into an implementation model. Even while for both models BPMN can be used, at some point, the purpose of the model changes. I believe that the purpose-change from analysis to implementation can not and should not happen automatically or transparantly.

In some cases, the BPMN model representing the executable process could very well be exactly the same as the original analysis diagram. In fact, the better the executable process language, the closer the implementation diagram will be to the original analysis diagram. William Vampenepe's post already shows that BPMN to BPEL doesn't really succeed in that goal.

BPMN to XPDL would be much closer, but XPDL doesn't really aim to be an executable process language.

BPMN to BPEL: Lipstick On A Pig?

Yesterday I came across William Vambenepe's blog post: BPMN to BPEL: going to battle with one hand tied? It shows that if you translate a simple BPMN model to BPEL, the BPEL process is not really recognizable any more. It seems to reconfirm my initial estimations about that kind of transformation.

I'm happy with the rapid adoption of BPMN in the BPM world. But I was always puzzled by the big focus of the BPMN to BPEL conversion. I have not done the excercise myself of trying to write an algorithm that did such a transformation because the models just don't seem to fit. BPEL is a composite (aka block) structured language. BPMN is graph based. BPMN is focussed on process analysis, while BPEL is about orchestrating web services. And in my experience, the non tech business analysts don't think in terms of web services.