Process for the Enterprise » jBPM

Sign of the Times for jBPM

Scott Francis — Wed, 12 Jan 2011 21:08:38 +0000

Just read the first (last) post from the planetjBPM blog:

It has been over a year now since I posted here. Any of you who have been following development of opensource bpm solutions and jBPM in particular might have a clue about why it took so long (at least partially). Not that long ago, I made the ‘formal’ decision to not use jBPM anymore. It has to do with a new job, things within the project and alternative solutions.

It seems Activiti has stolen jBPM’s thunder. Folks like Ronald were critical to jBPM’s community.

Mark Little on jBPM 4 Support

Scott Francis — Wed, 19 May 2010 21:50:51 +0000

With all the hubbub about Activity, I have to admit I found Mark Little’s post about jBPM underwhelming. After four rambling paragraphs about the historical ties between jBPM and the rest of jBoss (much like the pre-amble you hear right before someone says “…buttttttt…..” ), Mark finally gets to the point. By this time, I was waiting for the axe to fall.

But of course things don’t always run according to plan and 6 years after joining, Tom decided to leave for pastures new. That left us with a new jBPM lead, Alejandro, who has been a skilled engineer working on the project for many years. It also coincided with the release of SOA-P 5.0 and a need to continue the workflow rethink that had been going on for quite a while. Naturally the departure of any project lead may cause worries in the community and with customers, but where jBPM is concerned they are unfounded: jBPM has been core to all of our BPM and SOA efforts for years and that will remain the case, whoever is the project lead.

Oh wait. That wasn’t the point yet. Ah, here it is, two paragraphs later:

However, it seems that there remain concerns around jBPM 4. Will it be productized? Will it be supported (really the same as the first question)? Will we put any engineering effort into it? It is fair to say that there was expectation that jBPM 4 would appear in a version of the SOA Platform as a replacement for jBPM 3. With the changes to the jBPM project team and the next steps in unifying our efforts in this area across projects, it is not going to happen.

Mark reassures the jBPM faithful that they will continue to invest in jBPM 4 and release new versions. But RedHat isn’t going to offer paid support for it, and yet they don’t have a plan for jBPM 5 yet. There’s a pretty tough thread on the discussion forums. You can’t help but feel for people who’ve advocated for jBPM4 who now feel abandoned because they or their customers cannot purchase jBPM4 support contracts.

I think the interesting part is that Mark doesn’t seem to understand what all the fuss is about. The comment thread on his blog is an interesting read. Mark’s first response to a very tough criticism (from Mark Roy) of the handling of the transition is:

Mark, I’m surprised and disappointed that you feel that this transition has been handled poorly. The team needed to think things through before making many public statements and that’s the right thing to do. I don’t think the community or our customers would thank us for making rash statements that we then retracted only a few days later. And let’s be clear: it’s only been 3 weeks since Tom left and in the software business that’s hardly an eternity. [...]

Well, I think that the open source community expects to be involved in the discussions. They feel an ownership of the project, because they’ve invested in it. They want to be able to make their case *before* a final decision has been made behind closed doors, not after. Managing communities (open source or otherwise) is tough. Mark and his team have their work cut out to rebuild trust in the jBPM community. I’m not an expert on the jBPM community or the politics within open source communities in general, but I thought this kind of support angst only happened with commercial software!

A Career in #BPM Pays Off

Scott Francis — Sat, 30 Jan 2010 18:02:58 +0000

Lest there be any doubt that BPM skills are in demand, Tom Baeyens has pointed out that SimplyHired stats claims the average jBPM salary in CA is US$114,000. Not bad. Lombardi BPM shows similar numbers. It supports what we’ve been saying all along – BPM skills are in demand, and it should be a great career for the next decade (or two, or more). Its just hard to see “process” going away as an important concept in business. So what the SimplyHired stats tell us is that the technical side of BPM is in demand – regardless of the tool set, there is a mismatch between supply and demand right now that is going to take time to fill – and knowing the technical side of the coin is only half of it – the other half being the business process side of things. I can tell you from experience that not all great technical people have an interest in business process, and not all of them can make the adjustment to focusing on the process over the technology.

In the meantime, your best bet to get up to speed is to get a job that will let you learn on the job, attend training, etc. There really aren’t any formal education programs at universities that are widely recognized (although there are a small number of universities that have a small number of opportunities to learn about business processes). There are classes you can take from the software vendors or the likes of Bruce Silver, and there are certification programs- but no sense paying for certification until you know what you’re doing. Once you get started, then try to take advantage of the many resources on the net, and resources like bpmCamp.

Apple’s Strategy Pays Off

Tom Baeyens on Blending Process and Rules

Scott Francis — Tue, 19 Jan 2010 14:57:49 +0000

Tom continues to update the world with jBPM updates – in this case, using jBPM 4 and Drools to blend process and rules. His updates definitely play to the technical audience rather than the business – but I don’t find that too surprising in the open source world. From a technical perspective, it is certainly interesting. Proof that these memes seem to emerge on their own : Bruce Silver has also recently posted on rules and BPM (part 2 of a previous effort).

At some point I look forward to digging into jBPM more thoroughly, and now that it supports BPMN 2, I’m more inclined to make the time, its starting to get interesting for the kinds of problems we look at. However, I still fear that it is just a bit too technical in terms of what it requires of process authors still.

A previous update confirms that jBPM now supports BPMN 2.0, as of version 4.0. This is a niche I think open source can help fill – potentially fully implementing a spec that probably won’t be fully implemented by any commercial software vendor. (Filling out the corners is just the kind of academic exercise that seems to get tackled by *someone* within an open source effort)

jBPM supporting BPMN2

Scott Francis — Thu, 10 Dec 2009 14:27:07 +0000

Pretty interesting update from Joram Barrez on jBPM – looks like it now supports BPMN2.0. (or, more accurately, it will come January 1st).

Its a pretty interesting look under the hood of one of the top open-source solutions in the BPM space. The BPMN2 implementation uses the jBoss PVM (process virtual machine) to execute the BPMN, rather than transforming BPMN into BPEL or JPDL or some other XML format.

jBPM also gives the developer a good Java programmatic interface into the BPM engine implementation (and, the processes it runs).

This sort of development effort does make me wonder if, eventually, we’ll have a fairly standardized open-source BPMN engine with commercial products that incorporate it in different ways (picture Apache or jBoss as examples, or the WebKit in the browser world). Hard to say if jBPM (or key pieces like PVM) will turn out to be that open-source engine of choice, but at least from the blog posts it seems like they’re taking an intelligent and focused approach.

Tom Baeyens on jBPM 4.0

Scott Francis — Mon, 23 Mar 2009 02:35:01 +0000

Tom’s blog is one of my favorite to keep track of, partly because he takes a fairly pure software engineering approach to the business problem of BPM. It sounds ironic perhaps, that I would find this interesting, given that our focus at BP3 is all about business process improvement, and *business* results. However, there is something refreshing about Tom’s approach to BPM, as embodied in the jBPM project. There is also something pure about trying to provide tooling for a problem, without worrying about certain commercial interests that affect the behavior of enterprise software vendors.

I still think the commercial vendors are providing an overall user experience that is closer to what the business (and IT) wants out of BPM for truly business-facing processes. However, efforts like jBPM have a real chance at becoming the de-facto plumbing behind commercial products, by providing (as Tom would put it) a “bottom up” set of foundational building blocks that build up to what you need for a BPM solution. Will jBPM be the chief open source answer to BPM the way that Apache was for web servers? Too early to tell, and there are other efforts – but if jBPM lives up to its billing, and its core team of contributors keep at it, it seems plausible.

I’ve been thinking about what would happen if someone took a very BPMN centric point of view and tried to overlay it on jBPM – could they describe all of the behaviors in jPDL? Would the Process Virtual Machine (PVM) have all the necessary primitives to support the BPMN aspects? Could the end-result be tied into an existing modeling framework/toolset?

Here’s the slideshow Tom gave at a recent BeJUG meeting:

jBPM 4 BeJUG Event March 20 2009

View more presentations from tombaeyens.

Thought-provoking article on “Seven Forms of BPM”

Scott Francis — Tue, 11 Nov 2008 12:32:44 +0000

I’m not sure there are exactly seven forms of BPM, but Tom Baeyens writes a thoughtful article here that lays out 7 use cases and how they are addressed by JBoss jBPM.

Before we even get to the 7 forms, Tom has an insight that is key to understanding why BPM systems are a bit “different”:

A key capability of BPM systems is that processes steps can be wait
states. For example in the business trip process above, nodes ‘manager
evaluation’ and ‘ticket purchase’ are human tasks. When the execution
of the process arrives in those nodes, the system executing the process
should wait till the assigned user completes the task.

From a software technical point of view that capability is a big deal. As the
alternative is a bunch of methods that are linked by HTTP requests,
Message Driven Beans (MDB), database triggers, task forms, etc. Even
when using the most applicable architectural components available in
Java today, it is still very easy to end up in a bunch of
unmaintainable hooks and eyes. Using an overall business process makes
it a lot easier to see and maintain the overall execution flow, even
from a software technical perspective.

I couldn’t agree more with this, though it is a sort of “under the hood” consideration. It is part of why well-designed BPMS packages can scale really well with respect to the number of process instances that might be in a resting state (waiting for something to happen). Any BPMS solution that is holding all these instances in memory is going to be at a distinct disadvantage because for most of the time a process instance is alive, it is in a waiting state, waiting for an activity to execute, for a human to act, etc. and not actively processing work.

Setting aside scale, its just hard work to write the code that surrounds such wait-states correctly and you don’t want to have to write this code every time you confront such a problem – rather, you want to use a BPMS that seamlessly represents these wait-states in a diagram, giving the developer the ability to focus on the functionality of the process steps or the flow of the process, and not get caught up on the internals.

A couple additional thoughts on the seven forms (use cases) he outlines…

For Use Case 5, Visual Programming, he lists a few benefits:

With visual programming, we will target developers that do not yet have
the full skillset to develop in Java. They can graphically specify the
activities and draw transitions to indicate the control flow. Instead
of typing Java code, just put blocks like ‘perform hql query’,
‘generate pdf’, ‘send email’, ‘read file’, ‘parse xml’, ‘send msg to
esb’. Instead of writing Java, they will be composing software programs
by linking activity boxes in the diagram and filling in the
configuration details.

While simplifying activities like stringing together queries and PDF generation without writing that code may make this operation more accessible to developers without these Java skills, I would contend a different benefit: Things that should be easy (or rote) become easy (or rote) and therefore free the mind to focus on the bigger business problem. This is akin to the value I receive from a BPM system hiding the details of implementation of parallelism from me. While I may have the skills to write this code, it is tedious to write, and expensive to get it right. So you don’t want to roll this kind of code in a one-off fashion – you want to write it once and re-use it liberally to get benefits of scale. To the extent that a visual environment frees the developer to focus on the important abstractions of the process, it is a big win. (Note: As soon as I read Use Case 6 it precisely points out my thoughts about threaded programming, by pointing out that you can use a BPM system as a thread control language).

What really intrigues me is whether Tom and the JBoss jBPM team can create the necessary interfaces and utilities around jBPM to allow the creation of the Domain Specific Languages that can be implemented in jBPM (e.g. BPMN). While Tom apparently doesn’t see much value in the use of BPMN for executable models, my experience differs (and, since his technical approach doesn’t preclude BPMN for executable models in the future, the disagreement is more theoretical). Perhaps we can change Tom’s mind about this! While I think it is possible (and even useful) to create BPMN models that are not intended for execution, I believe a good technical implementation can still be accomplished with BPMN (plus technical details captured in context of the process). And this technical implementation can still be understood by the Business.

I think the problem isn’t BPMN… its a lack of imagination about how to capture business and technical details in different layers so that the user of these authoring tools can show or hide the “layers” that are interesting to them. For clarity, I think “technical layer” could include adding additional BPMN elements to the diagram, not just scripting and code and variable input/output details. And I think tailoring the visibility of details in the diagram is a key component in making a single model multi-purpose in audience.

I’ll definitely have to keep my eye out for jBPM 4…