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.

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)

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’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:

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…