VOSibilities

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.

It’s one thing for jilted developers to find a new home, even one of convenience. It’s another to declare a whole new BPM religion that claims that the only right way to achieve BPM is inside of some point product, down where developers (the real targeted users of jBPM) can get at it.

Above all, BPM is a management discipline. As our CTO Michael Rowley is fond of saying, BPM can be done with pens, whiteboards and Post-It notes. That means that not every process ends up being automated. Of those that do (and of course, we believe that many processes do end up being automated), it makes no sense — none whatsoever — for those to be automated inside another type of product.

Instead, the real opportunity for BPMSs is to allow the extended development team to break down the design barriers of ECM, CRM, ERP, PLM and other application types to focus on the core business process. The desired process model is, literally, “above” the constraints and assumptions of the containing systems.

This isn’t to say that document management doesn’t need a BPMS — in fact, we’ve been among the first to demonstrate integration with Alfresco via CMIS to make precisely this point (here and here). But I don’t think anyone would stipulate that an assembly-line quality control process, branch bank customer marketing process, production of feature films or managing agricultural improvement are all fundamentally, inherently and exclusively document management processes (these are all examples of real customer processes deployed in ActiveVOS). But that’s what jBPM architect Tom Baeyens asserts when he argues that “standalone BPM products that don’t offer BPM where it’s [sic] used are…a dead end…”

Of course, we argue the precise opposite: that the problem with embedded workflow is that it’s too limited by its container.

The other big issue we have with the new Activiti BPMS recasting of jBPM is its apparent confusion about who will use it. On the one hand, Activiti says, “It’s easy to understand that the future of BPM is BPMN 2.0.” (We agree.) On the other, just a few lines away in their FAQ, this plum: “Is BPMN 2.0 readable enough for developers?”

This is code (sorry) for the fact that while it’s not possible today to introduce a BPMS without genuflecting at the BPMN 2.0 altar, there are precious few who have stepped up to the challenge of making BPMN 2.0 work for both developers and end users. That is, BPMSs that offer no other visualization of the process model. That’s what we believe: that BPMN 2.0 is the notation of process (and BPEL is its execution engine). The goal is to make the BPMN 2.0 modeler so complete — yet so simple to use — that anyone on the extended team can instantly “get it.” You can already tell from Activiti BPM’s ambivalence about BPMN 2.0 that their BPMS will suffer from a common affliction: devolution into either an end-user “pretty picture” tool or (much more likely in this case) a tool for developers only.

So, we welcome the debate about the future of BPM. But we think the real debate is about a single, external BPM system that everyone can use…not some “off” combination buried inside another product which is neither fish nor fowl.

Tags: activiti, alfresco, BPM, document management, ecm

This entry was posted on Monday, May 17th, 2010 at 5:35 pm and is filed under BPM, BPMS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.