In a first post called "Activiti BPMS: neither fish nor fowl", Alex Neihaus (VP Marketing, Active Endpoints) starts with the coolest picture I've seen in a while:
The rest of that post is rather poor in terms of facts. He says
we’ve got no issue with the jBPM team moving to greener pastures to try and rescue a moribund open source project
The term moribund (means "in terminal decline") is hilarious if you know that jBPM had 25000 downloads per month. I don't know of any other BPM System being used as much. Further on, despite what is insinuated, we agree with the next part:
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.They probably didn't take the time to go through our website. In our very first FAQ "What is BPM?" in which we clearly distinct between BPM as a management discipline and BPM as software engineering:
BPM as a management discipline is the responsibility of every strategic executive manager. It's to ensure that the organization performs well in their core business processes. ... This means analyzing, documenting and improving the way that people and systems work together. As part of that work, it's useful to work with models and diagrams. ... Important to note that these models are used for people to people communication. ...
BPM as software engineering means that executable business processes will be executed by a BPM System (BPMS). ...
The attention continues with Michael Rowley adding more argumentation in "Activiti BPM: is a process microkernel the way to go?" Michael start with
The idea of the process virtual machine is simple and appealing
So far so good.
The idea is that all of the hard work of developing a process engine can be put into a layer that is more general and abstract than any process definition language. Then, when anyone wants to create a process engine based on a new language, it is a simple matter to map the concepts of the new language onto the constructs of the PVM and voila: a new process engine!
Exactly! We did it for jPDL, BPEL, SEAM Pageflow, XPDL and now BPMN 2.0.
The link to Linus Torvalds microkernel stuff doesn't have any substance and it's pure FUD. Active Endpoints only makes a core piece open source (ActiveBPEL, GPL) and for which the actual product contains commercial licensed software:
You can use the ActiveBPEL engine under GPL v2 by downloading it from this website. Alternatively, you can acquire a Commercial License to Active Endpoints' ActiveVOS Enterprise product by contacting Active Endpoints.
For such company to use Linus Torvalds as part of their argumentation is actually ironic.
Then Michael aimes his guns on the Process Virtual Machine (PVM)
A traditionally developed BPMS will be on top of an application server and a database. The application server is on a JVM, which is on an operating system, which often is on top of a virtual machine. Every layer adds value but it also adds cost ... Is the cost/benefit tradeoff right for a PVM layer?
I’d say no.
I'ld say yes. In Activiti, the PVM actually runs BPMN 2.0 natively. So it's removing a level of indirection, rather then introducing one. The PVM itself is transparent. So if there is an error, you get a the error in the context of a BPMN 2.0 process. The structure of the PVM process is a 1-1 match with the structure of the original process. Same goes for all the other languages we ever built on the Process Virtual Machine.
Let's compare this to the alternative strategy proposed by Michael Rowley: BPMN to BPEL translation. Historically, BPEL is actually a graphical language and it was long time promoted as a real BPM language that business people could draw. Over the last 2-3 years, there has grown a general consensus that BPEL is capable, but not suited for BPM. More precise, BPEL might be good at orchestrating web services, but it is a clumsy way of doing BPM.
Then comes BPMN. I speculating that their engine architecture is not that flexible. Because now their solution is to translate BPMN into BPEL. Translating from one graphical language (BPMN) to another graphical language (BPEL) is adding an unecessary level of indirection. The BPEL still needs to be interpreted by an engine. And when then an error occurs, you get a BPEL error, not a BPMN error. And secondly, the translation step from BPMN to BPEL is very problematic to say the least. So I can understand that they are not at easy with our new Activiti project running BPMN 2.0 natively.
The general tone of the posts try to imply that Activiti is only for developers. But that's just one aspect of our new project. Developers form one important target group to which we want to bring BPM capabilities. Alfresco ECM customers is another very important group. Both groups will benefit from our practical approach to facilitating collaboration between business people, IT folks and system operators.
So in my opinion, the only way I can interpret this attention is as pure FUD from a scared vendor. We're honored with so much recognition in our very first week ;-)