jBPM 4.0.0.Beta2 Released

Give this Beta2 release a try. Lot's of things were improved. Feedback appreciated.

JAX jBPM 4 Sneak Preview Slides

I've posted the slides of my jBPM 4 Sneak Preview talk yesterday at the JAX conference. First part is the same as the BeJUG presentation from last month. But the second part contains some concrete new examples of how to use jBPM 4 and what it can do.

jBPM Case Studies

Check out these case studies showing how jBPM is used in various industries like government, telecom, health care, biotech and as OEM. Thanks to the contributing companies: Enernoc, Advent conferencing, Booz Allen Hamilton, Crix International, SK Telecom, Vivat, Lexicon Genetics, Nuxeo and DST Health Solutions.

jBPM 4.0.0.Beta1 Released

jBPM 4.0.0.Beta 1 is out. Go get it here. We've added task management capabilities like candidates and swimlanes. More details in our JIRA.

Spring and jBPM

A session to look out for: "Spring integration in jBPM 4" by Andries Inze at next week's J-Spring event by NLJUG. The event is basically booked. But as people notify that their not coming, registration is activated again.

jBPM 4 sneak preview at JAX Conference

I'll be presenting a jBPM 4 sneak preview at JAX 09, April 21st 10:00 - 11:15

Get ready for the next generation of software development. jBPM 4 will deliver BPM to the masses. This session will start by highlighting the typical pitfalls of BPM and workflow technologies. jBPM can plug straight into your application's architecture. Learn how developers can structure their code around a combination of domain model and business processes. A couple of example scenarios will show the powerful features of jBPM. Apart from the business use case, this presentation will also highlight jBPM's capability to covers a range of technical use cases like orchestrating asynchronous architectures.

jBPM Slides Of The BeJUG Event Yesterday

Yesterday, I gave a jBPM 4 introduction for the BeJUG. The slides are available on slideshare. Check out the other BeJUG events, there are some real nice ones to come.

jBPM 4 BeJUG Event March 20 2009

View more presentations from tombaeyens.

Good jBPM Documentation Articles

Just came across http://www.mastertheboss.com Fransesco Marchioni and Mark Spencer posted some nice jBPM articles. Especially the jBPM Best Practices article is worth a read.

Great work, guys!

BeJUG jBPM Event Now Thursday In Ghent

Don't miss out on the next BeJUG event now thursday. Take this opportunity to connect with the core jBPM community developers!

Tuning jBPM In A Cluster

Szymon Zeslawski has posted a great TSS article: Scalability and Performance of jBPM Workflow Engine in a JBoss Cluster.

The verdict is that jBPM is a very efficient workflow engine, it only requires turning the right knobs in order to get the most out of it.

That is indeed the spot that we're working hard to resolve in jBPM 4: better tuning defaults and that way try to postpone the need for custom tuning when scaling out.

By adding 3 servers and tweaking jBPM configuration, we were able to increase the throughput over 16 times in comparison to 1 server environment with default setup.

Awsome !

Next jBPM Community Day is May8th in Antwerp, Belgium

It will be hard to match the Dublin jBPM Community Day from last year. But we sure are going to give it a good try an Antwerp. Mark May 8th in your calendar, start to book your flights and get some rest upfront.

More details in this wiki page

3 Approaches To Transform Analysis Diagrams Into Executable Processes

Finally a good blog discussion related to the reason of existence for Business Process Management (BPM). It's about how analysis diagrams get transformed into executable processes.

Scott Francis' post Compliance for the BPMN Specification… Shooting the Moon? already gives real good comments on the recent blogs. That is what triggered me to put the approaches that I know of in a list.

When considering BPM as a management discipline, the goal is that the business people should be in control. So business people, which usually don't have a lot of software development skills, create diagrams to document how people and systems work together. These I'll refer to as analysis diagrams. In this context, BPMN is currently getting a lot of attention.

On the other hand, it might be decided that software support for these processes will be developed. In that context, an executable process is a piece of software that can be executed on a BPM System (BPMS) and which also has a graphical representation. The only real executable process language standard currently around is BPEL. But BPEL targets what I describe as a completely different use case, namely service orchestration.

That brings us to the obvious question of how are analysis diagrams different from executable processes and how to bridge between them. This is where *finally* an interesting debate is starting at the heart of BPM.

Here are the 3 approaches:

1) I'll start with our own approach, as of course, that is the best :-)

We believe that analysis diagrams can be created in many notations, BPMN being one of them. Then it is up to the IT department to select the best process language that fits with their needs and then produce an executable process that looks exactly like the analysis diagram. That way the diagram remains an excellent instrument in the communication between IT and business people. But as an executable process is actually software, it should te governed by the IT department. In a previous post about BPMN 2.0 I elaborate a bit more on how we see the collaboration between analysts and developers.

This approach is quite similar to those who claim that we should move to executable BPMN. BPMN 2.0 will most likely incorporate explicit execution semantics for all the diagram elements. I believe that this is a very pragmatic move by Oracle and IBM as they have BPEL products and pure-play BPM products in their portfolio. For the pure-play BPM products, the executable BPMN route basically puts the translation to an executable process under the hood and makes it therefor irrelevant. That way, the pure-play BPM vendors are not forced to use BPEL underneith as the mapping between BPMN and BPEL is basically broken.

But in our view, a naive adoption of making BPMN executable can easily lead to trouble. It's generally accepted that process diagrams need to be decorated with technical details before they can be executed on a BPMS. Most of thos technical details that do not translate to the business side.

But the same is true the other way round: be very careful with expressing too much business level details in the diagram as they might not translate to the executable process. So you want to keep those out of sight of the business analyst. In many cases a lot of those graphical notation bells and whistles are actually technical details. So if the naive way of making BPMN executable results into graphical programming, then it is not suited to support BPM as a management discipline. Business analysts should be able to model freely without being constrained by technical details.

So in conclusion, the primary focus of bridging between analysis diagrams and executable processes should revolve around just the basic boxes and arrows. That is the intersection that can facilitate communication between business and IT.

2) Another approach is roundtripping. As said above, most people have realized that this is basically broken... unless... You can develop so much tooling around it like Oracle or IBM. With a vast amount of tooling a BPMN diagram can be translated to an executable process in e.g. BPEL and then synchronization links can be maintained so that roundtripping becomes an option.

The downside of this is that the user actually has to maintain the synchronization links. A lot of effort will be spend by the developer team to feed in the synchronization information. And still the changes that are generated to the executable process when a business analyst updates the analysis diagram, will never be transparant. In most cases. the development team will still have to intervene and merge the changes and verify the interactions between the process and verify the correct operation of the process in the context of other related software components.

And IMO, some teams might spend the time to maintain 2 models and keep them synchronized, but in general, I think this is undermining a big part of the agility value of BPM.

3) The third approach I'll discuss here is expressed by Ismael Ghalimi in Why BPEL Matters.

In their approach comes down to mapping BPMN to BPEL. But he also adds that the resulting BPEL process should be considered as the bytecode.

In this approach there is a believe that an analyst diagram can be decorated with technical details to make it executable. I don't see yet how this can lead to anything else then graphical programming.

I'm really puzzled by this approach as it seems to me that it is taking the worst of two worlds. On the one hand, they create a hard link between the analysis diagram and the executable diagram which blocks the analyst from modeling freely. And secondly, why would you perform a clumsy translation to BPEL if it's kept under the hood? I could think of easier ways to execute BPMN natively then through a translation to BPEL.

If BPEL should remain under the hood, then I don't get why BPEL is so important? I agree with the standardization argument. But they are also building SimPEL, which he describes as a different syntax for BPEL.

Another point that I wish to challenge is that BPEL supports distributed transactions. Afaict, BPEL doesn't specify when the state of a process should be persisted and it doesn't state how that persistence should participate in a transaction, let alone how it should participate in a distributed transaction that spans multiple systems.

Let me know if I'm missing something.

3 BPM Blogs You Want To Subscribe To

Here are some top notch blogs that I have *have* to recommend:

1) Leadership BPM by Rashid N. Khan

Last year, Rashid retired as the CEO of Ultimus and now he started a blog in which he shares his vast amount of experience.

During this period I was involved in 100s of BPM deployments worldwide and collected a wealth of experience. Now that I have retired from Ultimus, I want to leverage this expeience and help senior executives to learn about and benefit from BPM and related technologies. I have a unique perspective and I have been very focused on the practical, nuts-and-bolts issues about BPM that senior executives have to understand if they are going to fully realize the potential of BPM.

The nice thing is that he now can give an independent, unconstrained look on things. Opinions of that skill and which can speek freely are hard to find.

In What it will take to deliver BPM as SaaS?, he already seems to pinpoint the crucial conditions of the latest BPM as a service hype.

In my judgment BPM SaaS has to have the following characteristics as a minimum. First, it must have the ability to model and modify executable processes in a hosted application. The ability to design executable processes, in contrast to simple flow diagram, is pretty challenging. ... Second, BPM SaaS must have the ability to allow customers to integrate with their inside-the-firewall data and other applications. This is crucial because BPM deals with company’s data and interacts with other applications. Without effective integration only the very simplistic BPM processes are candidates for SaaS, and CxOs are reluctant to invest money or mindshare on simplistic processes. Integration is the Achille’s heel of BPM SaaS and solutions for this will evolve only gradually. Perhaps the best approach for BPM vendors is the emerging class of "application appliances" that leverage virtualization technology to deliver inside-the-firewall solutions on a SaaS basis. This has the potential of solving the integration problem. I will discuss it in another blog as this is a topic on its own. Third, and easiest, is the ability for end-users to participate in business processes using a browser. ... Fourth, BPM SaaS must provide a means for customers to monitor and administer their processes over the Internet. Again, with the emergence of AJAX and RIAs, this is not a challenging obstacle. And fifth, BPM SaaS must provide some web-based reporting, BI and BAM capabilities.

In Is the BPM Industry stuck in no-man’s land?, Rashid starts by pointing out that BPM systems didn't get to the mainstream as they always envisioned:

Even if I take a conservative forecast and assume that the market was $1 billion in 1998 and growing at 15% per annum, it should be at least $4 billion today. But the most recent forecast continue to put it in the $2 billion range. So where does all the growth fizzle away? Second, every BPM vendor and analyst can provide a number of actual case studies of BPM deployments that demonstrate remarkable ROI and productivity benefits. And it is relatively easy for senior management to understand why BPM can deliver such results. Yet the penetration of BPM in organizations is still small and I would venture to say that less than 10% of processes are automated despite all the ROI and productivity proof points. Third, every year BPM vendors claim impressive growth and publish a roster of new customers. Yet most pure-play BPM vendors are relatively small companies and none have been able to go public despite the claims of growth and the fact that many of them have raised tens of millions of dollars in venture capital.

This is exactly what I thought as well and in my opinion this is largely due to the fact that executable processes should be part of the software applications themselves. The big problem still to date is that BPM Systems are considered as monolithic applications that are hard to integrate into a software development project. That is exactly the problem that we have focussed on in jBPM since the very beginning. And indeed it is not an easy one. Rashid seems to come to a similar conclusion:

First, BPM sounds glamorous, but it is not easy. This is because human beings work in extremely complex ways. Developing software that caters to all these ways is not easy. The “human interface” of BPM is complex and challenging. Second, the IT environments in which BPM has to thrive are very complex, varied and in constant flux. BPM cannot be successful without seamless integration with the rest of the IT infrastructure.

I hope that Rashid keeps up sharing his points of view.

What's cool for me is that when I started jBPM, Ultimus is actually the first product I looked at to see what the competition was like.

2) Small steps with big feet by Joram Barrez

Joram is a BPM and jBPM guru that I had the opportunity to collaborate with on a few occasions. For all your jBPM performance concerns, make sure you read his blog or get him involved. He tweaked jBPM performance better then we did !

His latest blog Blogs about jBPM you don’t want to miss! provides links to a lot of interesting jBPM related posts that are very informative.

3) PlanetjBPM by Ronald van Kuijk (aka kukeltje)

Ronald provides great practical tips and tricks on jBPM. He's another BPM and jBPM guru calling himself rightfully the jBPM Forum Addict. In practice this means that he helped thousands of people getting started with jBPM over the last 5 years by answering basically every question on the jBPM user forum.

BPEL versus BPM

Pierre Vigneras wrote a nice article on InfoQ about how BPEL is not the right solution for BPM. As you might know that is what I have been saying for a long time. Also the discussion that follows the article is quite interesting.

Seven Forms Of BPM

My article Seven Forms Of BPM with JBoss jBPM just got published on dzone. In this article, I explain 7 distinct concrete forms of BPM. Some are more business oriented and some are more technical oriented. BPM is a hugely overloaded term, resulting in a lot of confusion. Hopefully this article helps to clear out at least some of the confusion.

If you don't like clicking your way through the pages, consider the printer friendly format of the article.