Well, its only the second day since the Activiti news hit the wire and we have quite a few reactions.  Kudos to Theo Priestley for an unconventional take:

But there’s something else brewing under the surface. Whilst I could have focused on a review based on a powerpoint presentation, Tom’s direction made it pretty clear that he’s throwing down the gauntlet to the likes of Bonitasoft; we’re going with Apache and we’re going to win.

As Theo points out, there has been, lately, less vocal support of open source BPM – Intalio has been a bit quieter, and to the extent anyone is getting press, it is Bonitasoft – while jBPM went largely unnoticed outside of the developer community.

On our call with Tom and the Alfresco team, we specifically asked about the licensing – why Apache instead of LGPL – (honestly, I thought both were reasonably permissive) – and John Newton expressed the point of view that most software vendors were very comfortable with the Apache license, and not as comfortable with LGPL. So they believe more software vendors will be likely to take up Activiti as an embedded solution.

I think it is a good goal to make Activity embeddable.  But I advise them not to lose sight of having a good, complete, solution as well – which I believe is much of the secret sauce behind Bonita’s rise: they’re attempting to solve the whole problem, not just part of it.

ActiveVos takes a harder line view of the Activiti team throwing BPEL under the bus:

Today, Alfresco announced that it had digested the former developers of the jBPM project from JBoss. jBPM had never really made much of an impact as a BPMS because its real purpose in life was to cater to a core Java developer community. Much as hard-core coders might hate it, BPM is about collaboration among an extended development team that includes business users, analysts, developers and operations staff. jBPM was limited to developers and too proprietary to get much traction across the extended development team.

Let me be clear…we’ve got no issue with the jBPM team moving to greener pastures to try and rescue a moribund open source project. We do, however, have a very strong reaction to the transparently re-thought propaganda surrounding their new strategy. It feels like the jBPM architects have something to get off their chest about BPM in general… something they couldn’t get across inside JBoss and they’ve picked what is a rather run-of-the-mill addition of process capability to a document management system to proclaim a completely new metaphor for BPMSs.

Ouch.  I think Alex has a point: that the Activiti team could have made their announcement with no mention of BPEL at all and I don’t think it would have hurt their announcement.  However, I do think that Activiti is prioritizing correctly on BPMN2 first, and other process engine back-ends as lower priority for the core team.  If the project takes off, no doubt someone will contribute hooks to a commercial BPEL engine, or provide an open source implementation project for BPEL. There’s no reason that Tom and his core team have to provide this – at the beginning they’ll have limited resources and they need to focus on the most important bits first.

My biggest concern is how they build momentum around addressing the end-user concerns, starting from such an engineering-focused point.  It can be done – but only if really good APIs form the boundary between the BPM and the UI, and that good projects are started around the UI software that will expose BPM to the masses.

There’s been a lot of gnashing of teeth about the state of BPM vendors, and the BPM segment, ever since IBM announced its acquisition of Lombardi (and followed quickly by Progress’ acquisition of Savvion).  Even before then, there was much discussion over whether BPM really was a bright spot in the enterprise software space – could it really be growing when everyone else was struggling to tread water?

And since these acquisitions, the attention has often turned to case management (or, the nom du jour, “Adaptive” Case Management), and some have argued that “BPM” as imagined by advocates of BPMN is in trouble.   Of course, as with many things, one way to measure “success” is by whether the businesses advocating a particular approach are doing well – and doing well is typically defined as increasing revenue (and/or profit).  Ironically, if such a firm makes money, critics will say this only proves that the firms are good at making money, not that the software or approach to BPM is adding value for customers.  But we have to accept that in the long run, averaged over *many* decisions, the market assesses value by assigning dollars (or euros, etc.) to the products that are perceived to add value, and starving the products that don’t add value by not making purchasing decisions.

Dennis Byron says the big enterprise software firms are well-positioned to take advantage of the BPM “explosion.”  Meanwhile the independents don’t appear to be suffering.  The latest report from MWD summarizes results from Appian and Active Endpoints, two vendors who wholeheartedly support BPMN (Appian with a SaaS model, and Active Endpoints with a BPMN-up-front and BPEL-in-the-back approach).

Key data points:

Appian highlighted the growth of customer orders by 58% from Q4 2009 to Q1 2010 (and this isn’t a seasonal thing with Appian; in 2008 its Q4 was its largest quarter). Active Endpoints highlighted revenue from new customers: it tripled in Q1 2010 over the same quarter in 2009 – contributing to an overall doubling in revenue against the same period a year earlier.

Bigger firms like Pega are doing just fine as well, according to their quarterly reports.  So this is a good indicator of increasing demand for BPM software.  The increased demand for BPM skills, education, and even consulting is sure to follow.  It is an exciting time to be in the BPM market. Congratulations to these firms for having good Q1 results.

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.