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.

Its hard to keep this argument buried, as Bruce Silver demonstrates in yet another post on this subject, reacting to yet another response from the BPEL crowd.  I was going to respond directly in his post here, but for some reason I couldn’t comment on his site today.

Bruce makes the killer arguments:  only a subset of BPMN is “isomorphic” to BPEL.  Quite simply: BPMN allows the author to represent process flows that BPEL cannot represent accurately in a model-preserving fashion.

There was an argument put forth that wouldn’t these limitations be true of proprietary execution implementations as well?  And the answer is – perhaps – if those execution implementations don’t account for tricky stuff like interleaving (my experience is, that they do).  The difference (mainly) is that these “proprietary” execution implementations speak BPMN natively and were designed from the ground up to support the use cases defined by BPMN. The same cannot be said for BPEL and the engines which implement primarily BPEL. An engine could do both – but I don’t think the right answer is translating BPMN to BPEL to get there.

And we couldn’t agree more.

In this post, Bruce rips into a post from ActiveVOS which claims that BPMN->BPEL is simpler than using BPMN.  ActiveVos’ CTO Michael Rowley points out that because of BPMN’s focus on communicating between people (I believe that he means, sharing process definitions so that two people can come to consensus) is also a weakness of the standard – because this people-centric view is bound to cause it to evolve and change over time.  Mr Rowley has it backwards – the point of “code” isn’t to communicate to a machine to get it to do something!  The real purpose of code is to expose an interface into the machine that is understandable by humans – note: the audience is for humanity, the audience is not the machine.  Otherwise we’d have to write machine code (hex or binary) to write programs.  Or assembler.  Languages make the machine instructions and behaviors more accessible to humans, and that is what they are there for.

Also, the most costly thing about code is that so few of us really understand what it does – even really well-written code – making maintenance over time very expensive.  If BPMN is understandable by a greater number of people, that makes it more valuable than BPEL, which as an XML standard is understandable by relatively few people.  The fact that this expressiveness is challenging to the engineering teams who have to turn this into process execution is beside the point – after all, Rational Software did it for UML, there is no reason that BPMS vendors can’t do it for BPMN.  In fact, we can see that BPMS vendors are meeting this standard, despite the fact that they are each proceeding at a different pace on this trajectory.

Bruce’s post is worth a read, but my favorite points are these:

However, for process modelers, and even for executable process designers, there’s no way BPEL execution makes BPMN modeling “simpler.”  That’s because the subset of BPMN supported with BPEL execution excludes the very features that make BPMN attractive to business-oriented modelers in the first place: things like freeform looping back to a previous step in the flow.  BPEL is inherently block oriented, like a computer program, while BPMN is inherently graph oriented, like a flowchart.

Right. From the modeling point of view I don’t care what the engine is as long as it faithfully implements everything I’m modeling without losing any fidelity.

And Bruce wraps up with:

If BPEL were adequate to execute processes the way business wants to model them, it would have become the BPM runtime standard.  It hasn’t.

Well said, Bruce.

Max J Pucher writes a pretty thorough rebuttal of the idea that BPEL matters.  He starts by pointing out that the defenders of BPEL often malign those who question BPEL’s utility.  Mr. Pucher has quite a few controversial posts and discussions in the BPM space, and this post is no exception. I can summarize his article in a few key points:

• BPEL is not widely supported.  There are over 200 BPM vendors, and less than 10% support BPEL, and by Mr. Pucher’s reckoning, their support is partial at best.
• Avoiding “vendor lock-in” is not a valid goal of BPEL – because there is still vendor lock-in with BPEL implementing products.  I happen to agree that it is a bit naive to think that software you buy from a software vendor won’t entail a certain amount of vendor lock-in.  Transferring execution details from one body of software to another and expecting complete faithful reproduction is non-trivial.  Just think about Java Virtual Machines – without a robust specification test to validate against, these JVM’s would never approach parity.  Even so, software vendors usually only warranty their products against particular JVMs and even JVM versions. He quite rightly points out that the combinatorics on database, OS, JVM, appserver, rules, security, etc. make it nearly impossible that an implementation can merely be lifted from one BPEL vendor and run inside another BPEL vendor’s platform.
• Since BPEL is XML that we hope never to lay eyes on, why is it the representation that we hope to preserve?  Aren’t the diagrams more useful to preserve?
• BPEL doesn’t address key business requirements – such as monitoring the execution of the process for important business metrics.  And the business shouldn’t really care how the process is executed so much as those metrics… So is BPEL missing the point?

His conclusion:

Conclusion: When BPEL and even BPMN are looked at from a pragmatic business need perspective the only acceptable benefit is that products that use them have similar functionality and people designing processes will find it easier to switch products.[...]

Well, this is a significant benefit – but it is not what the vendors of BPEL vendors will claim – “model portability” and vendor independence.  As usual, interesting stuff from Mr. Pucher, and a little different perspective on the BPM space.

Coghead just closed its doors a couple days ago.  I first saw the news on techcrunch in this post:  Coghead Grinds To A Halt, Heads To The Deadpool.  And then the following day the news that SAP acquired Coghead’s IP and hired on some of their staff:  SAP Acquires Coghead’s Technology As It Looks Towards The Cloud (hopefully this means SAP will actually incorporate some of these ideas into its products).

Coghead may or may not be an example of a SaaS BPM tool.  It has typically been described as “a web-based enterprise software editor that featured an unusually intuitive interface”, and typical competitors were seen to be tools like Intuit’s Quickbase, though I imagine some others might consider Coghead a competitor.  I believe Intalio‘s BPEL engine was used under the hood at Coghead.

Part of what got my attention on this matter though, was TechCrunch reporting that Coghead received $11M in funding.  It reminded me of a previous discussion on Sandy’s Column2 blog regarding Appian’s funding round of $10M to fund the SaaS model Appian is increasingly moving to.  At the time, I felt that $10M might not be enough for a company to develop a successful SaaS solution.  Although SaaS seems like a low-cost way to get a business started, and it *is* in many respects, customers also don’t sign big up-front checks in most cases- a few of which can solve lots of funding problems: specifically cashflow problems.  Spreading that cashflow over 3 years, for example, may be sensible, but it is really a transfer of risk from customer to vendor (the increased risks: customer can cancel before paying the full amount, customer may be purchased/merged/forced into a failure to complete the transactions, vendor has to provision all equipment, vendor has to maintain a happy customer for 3 years to continue to collect the money).  On the other hand, once this model gets going, it can be very successful and sticky (see: Salesforce).

Regardless, Coghead shows that $10M may not be enough.  I think there are people in the business who could make that work, but if you are figuring SaaS out as you go, $10M can disappear all too quickly.

(PS-  I love the crunchbase widgets.  now all I need to do is find a wordpress widget/plugin that will add them auto-magically for me!)

Another flurry of updates in the BPMN vs. BPEL discussion: Bruce fires a shot across the bow here, and then Keith Swenson makes a response in his own blog, but there is also a pretty good discussion below Bruce’s post in the comment section.

I think it is either a sign of progress or weariness that the debate has gotten a bit more reasonable, in that no one is arguing BPEL over BPMN or BPMN over BPEL, there is simply a discussion of how to allow the two to live harmoniously.

Bruce makes key points I agree with:  we can’t make the success of “BPM” dependent on agreement on definitions – its very hard to get a consensus on the definition for something as vaguely termed as “Business Process Management.”  Moreover, there is no reason to believe that different organizations can’t make these decisions DIFFERENTLY based on their own unique culture, personnel, skills, etc.  In one organization, the business may have members that are technical enough to model valid BPMN diagrams.  In another organization, those skills may go wanting, and the modeling will get done by IT.  In yet another, outsourcing the modeling and developing those models in JAD/RAD sessions may be the right approach.  Does anyone really expect something as broad as BPM to be a one-size-fits-all methodology?

Keith raises the point that BPEL isn’t enough to represent all the interesting process use-cases, and he’s right.  It doesn’t mean that BPMN and BPEL can’t play nice together, but it does mean that a “native” BPMN xml representation, independent of BPEL, makes sense.

Finally, Bruce raises the concern that this portability of models, and fidelity between diagram and XML representation, would likely be a good thing for any BPEL vendor, but the existing BPMN-native vendors might not get on board.  I think if the BPMN-native (my term for BPMS vendors who diagram BPMN processes and then execute those without losing fidelity, without translating into some other representation that doesn’t match 1:1 with BPMN) vendors won’t play ball with this portability, then it begs for an opensource project to help provide the import/export.  You’ll have one common storage (BPMN 2.0 presumably), and you’ll have a set of vendors with (potentially) proprietary storage.  That cries out for individuals to create the import/export mechanisms from each of these formats (based on which ones they know) as part of an open source project, if the vendors won’t do it on their own.

I’m still not sure it commoditizes the runtime however.  It commodotizes the storage definition… but one still has to write the code that will execute these models, and there will be room to compete on several fronts (performance, resource utilization, correctness, platform support, architectural compatibility, etc).  And hopefully the competition will move toward value-added features on top of these models and run-times… Because there is so much more to BPM in our future than just running these diagrams – and yet some of those future states may be hard to get to if we can’t make the basic blocking and tackling easier.

There has been a flurry of discussion around compliance for BPMN specifications, particularly on Bruce Silver’s blog, and with additional commentary from Ismael’s blog.

Bruce makes some great points about why BPMN is catching on in the marketplace.  It is (relatively) intuitive, it represents most of the really important ideas that need to be expressed in the Business Processes, and I’ll add another thought:  you can actually draw it on the whiteboard pretty accurately.  Some people think that is silly, but I think it matters that you can sketch it out pretty faithfully on a whiteboard or piece of paper as well as in software.  A great many people still think most freely on whiteboard/paper rather than on a computer screen.

Bruce also makes a great point about BPMN to BPEL mappings:

“A key reason for that is it is graph-oriented like a flowchart, not block-oriented like a structured program, or more to the point, like BPEL.  For example, you can loop back to some previous step with a BPMN gateway, but BPEL places severe restrictions on that.  What that means is you can draw BPMN diagrams that cannot be mapped to BPEL, or at least to “roundtrippable” BPEL that preserves the BPMN view after even minimal tweaking in the BPEL environment.”

Personally, I don’t even want “roundtrippable” I want “native” – meaning, a representation specifically designed to store BPMN.  Whether it is “custom” XML or “standards-based” XML, I want it to be targeted so that roundtripping simply isn’t an issue – the diagram is the xml/data and the xml/data is the diagram.  Otherwise, how can the business ever be sure that they’re BPMN diagram is being accurately executed?  If the representation isn’t roundtrippable or native, then it undermines faith that the process works as designed.  One of the key problems with all the previous software systems I’ve used and built prior to BPM is the separation between requirements and the finished solution (or, put another way, between the business and IT delivery).

Ismael of Intalio gives this response in his blog:

“Do not worry about round-tripping between BPMN and BPEL
Round-tripping is a futile and wasteful exercise when attempted between two languages or notations that have a significant semantic gap between them, and so is the case for BPMN and any process execution language optimized for computers (like BPEL). The same is true between UML and Java by the way. Round-tripping should be set as a goal only between two languages or notations that are essentially representing the same thing, such as BPMN and its future serialization format for example. What this means is that there must exist a way to fully serialize BPMN diagrams on one hand, and a way to graphically display serialized BPMN on the other. And all this should work in a deterministic and predictable way, uniformly across tools.”

I find the assertion that round-tripping is irrelevant to be a bit startling.  The problem is, if the translation from BPMN to BPEL representation is wrong, we’ll have a hard time detecting that.  And then how would it help with compliance? I can’t take the BPEL representation and load it in another BPMN tool and see the model… so we haven’t achieved the interchange that Bruce Silver is looking for, nor proven compliance…

Personally, I’d start with the following:

1. can i MODEL the specification model (ie, can i draw it in this tooling with standard components).  By this definition of compliance, a visio stencil may do the trick…
2. can the target environment EXECUTE the model.  the compliance model can describe the expected behavior of the model especially illuminating areas that might be up for debate (presently) but which should be standard (near future) interpretation.  Execution should be separated from modeling – from a compliance perspective – because BPMN does not exist solely for execution purposes.

Next, additional models could be provided that describe “illegal” models. If you model these in a compliant environment, it should, in some fashion, warn you that the model is not correct (either by throwing an informative error when you run/test the model, or by showing validation errors at design time).

Granted, testing compliance gets easier once BPMN 2 style storage spec gets released, but til then, there’s no reason we can’t have a representative model – it will just be harder to confirm compliance because we’ll have to actually do the work to model something.

Bruce points out that without the data storage spec, he’s not satisfied with the results – and I can’t blame him – but I think defining what would be a representative model to exercise the specification for a given tool is something that has to be done regardless of the storage medium.  And in the meantime, even the visual representation of such a model could help customers and consultants evaluate BPMN tooling appropriately for compliance.  Currently there’s just too much distance between here and there if we have to have a portable data schema before we can have a model (or set of models) that exhibits all the features of compliance.

Recently there has been quite an interesting discussion around Pi Calculus vs. Petri-Nets, and between BPEL and other implementations of BPMN.  The real discussion thread (consolidated place to read) is here.  The start of this discussion appears to be Ismael’s post on BPEL/Pi-Calculus vs. BPMN engines that use Petri-Nets.  This is pretty esoteric stuff to the average person, but it has sparked quite the debate.

You can find Ismael’s original post here.

If you’re technical, and you’re curious about what’s going on inside the black box BPMS you’re using, this is a great debate to read through.  The basic point made by Arthur and others is that BPEL is an implementation detail, and that BPMN is the most important standard because it represents the process, and as we all should know, representation affects how we think about process.  Arthur’s basic point is not that BPEL is deficient, but merely that it is like arguing about whether we should compile to Java bytecode or C-sharp byte code.  Or native machine code… do we really care as long as the code runs well on our target platform? :)

The victim in the debate is often “petri-nets” as compared to “pi-calculus”. Ismael makes the argument that BPEL is superior to the other approaches out there, partly because it is standards-based, and partly because it employs pi-calculus and that that is superior to petri nets for parallel processes. A great debate over whether BPEL really implements pi-calculus ensues, missing that the key point Arthur was making is that either a pi-calculus model or a petri-net model could represent parallel processing of BPMN models well. My personal experience reflects this as well, as I’ve participated in projects that leveraged both technologies and they both work… moreover, they don’t appear to be entirely mutually exclusive.

Lost in all of this debate is the B in BPMN:  The Business.  The Business doesn’t care as much about the specific technical differences of these approaches under the hood, so long as they execute the process faithfully.  Personally I just want to use the best tool for the job.  I’m going to “write” processes in BPMN.  I’m going to execute them and deal with differences in interpretation of the spec when BPMN is married up to execution engines, regardless of whether they are BPEL or other technologies (and the fact that it goes to BPEL doesn’t get me away from interpretation issues, because the issue is how is BPMN “interpreted” into BPEL just as much as it is an issue of interpreting BPMN into some other exeuction form).