Practical BPM Collaboration

There is a new form of Business Process Management (BPM) collaboration rising.

We have been exploring and documenting how we see the collaboration between business people, developers and sys admins in The Process Cycle Layer. Traditional BPM focusses on forward engineering or round trip engineering. But in our experience that is a bottleneck for mass adoption that we targeted previously and now with Activiti even more. In the Process Cycle Layer we sketch how that bottleneck in the collaboration can be removed by focussing on discussions, links and social interaction that spans the whole business process automation lifecycle.

Now, Bernd Ruecker just presented his ideas in Making the BPMN Roundtrip real. It turns out that those ideas align very well. They have been working out this idea in a project called camunda fox. This seems like a great validation of our thoughts. Very interesting stuff.

Next Level Integration Joins Activiti Team

We're proud to announce that Next Level Integration joins the Activiti team. Next Level Integration is a consultancy firm with expertise in B2B communications between utility companies in the energy sector.

Next Level Integration is the driving force behind the open source project B2B by Practice. B2B by Practice provides Integration capabilities for intercompany data exchange. It includes support for conformance processes related to the german electricity and gas regulations and order collaboration.

In that context of building solutions for utility companies they have a lot of experience with building massively scalable systems that have to cope with extremely high throughput. They will use Activiti as their BPM and orchestration engine in their B2B by Practice project.

In Activiti, they will focus on ensuring that massive scalability and they'll also focus on adding database pluggability plus support and continuous integration for a range of databases.

Christian and Stefan, welcome to the team! Looking forward to work with you.

Active Endpoints, Chicken And Activiti

We didn't anticipate to get that the launch of Activiti would get that much attention from BPEL vendor Active Endpoints. Nevertheless, we are very pleased with the recognition that can be implied from their reaction.

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 ;-)

On Brand, Credibility And Open Source Licenses

Bill Burke, a dear friend and respected JBoss Rockstar, posted some critical notes about the Apache vs LGPL license in response to Savio's "New BPM project questions value of LGPL"

Savio raises the point

On one hand, the JBoss Application Server, an LGPL licensed product, has garnered strong downloads and continues to grow revenue at a faster pace than Red Hat’s Linux business. It would seem that the LGPL hasn’t been a hindrance to JBoss Application Server adoption. On the other hand, as Newton points out, some ISVs, and as I’ve heard, some customers, remain concerned about viral licenses. While the LGPL was created to specifically address the viral nature of the GPL, some ISVs and customers remain weary.

To me, the most important difference between the LGPL and Apache license is summarized in: "some customers remain concerned about viral licenses"

I agree with a lot of points that Bill makes in response:

the OSS license chosen for a project is not that important as far as adoption or business goes. The most important driver for OSS is and always has been the brand of the project. Like their commercial counterparts, how the project is perceived by consumers is what drives both adoption and business. So, I agree, LGPL doesn’t add a lot of value.

and

If you boil it down, the distinctions betwen GPL, LGPL, and ASL are pretty much meanlingless to most consumers of OSS. How so? ...

I would rephrase those 2 quotes as "Brand and credibility is the most important aspect to an open source project, followed by the license".

But then I think Bill goes overboard on

The whole push by Apache.org and its minions that ASL is the one true license is just damaging to open source.

I'ld like to clarify that we don't consider Apache to be the one true license. It happens to be the license that allows us to exploit our brand and credibility, without being hindered by some customers' LGPL concerns (even if they would be unjustified). So it's more a practical choice instead of a religious one.

Back in 2003, a group of JBoss contributors tried to fork both the JBoss code base and the JBoss business. ... We then come full circle to 2010 with history repeating itself (well, sort of). You have Tom Baeyens leaving Red hat for Alfresco to create a competing BPM engine.

I don't see the association between those two events. On the contrary, I do see in the JBoss fork a confirmation that brand and credibility wins from license: JBoss brand was *much* stronger then CDN. Similarly, the JBoss brand and credibility was bigger then Gluecode/Geronimo credibility.

I even more disagree with

If you are an Apache guy, you should be appalled by behavior like this when it happens. Individuals and companies that use ASL as a weapon to further their own selfish and commercial needs should be castigated...

Well... everyone in this business wants to make a living. I don't think JBoss or LGPL-focused companies are different from companies working with Apache license in that respect ;-) It's a different kind of dynamics and you have to select what best suites your needs. In our case, we wanted to aim for mass adoption and scale out the community. The more liberal license has allowed us to unite more forces in one community then was possible in an LGPL/JBoss style. The community we have assembled up to now (4 days and counting;-) is far beyond what was possible before.

Granted, this comes at a price. We can't relax. We have to keep leading and keep making steady progress to prevent forking. If we stall, then the community will take over and fork more easily. I think this move deserves more recognition for courage, rather then being castigated.

As for LGPL vs. ASL? I could care less, it really doesn’t matter.

I take it you mean that the license of an open source project does not correlate 1 on 1 to its value. I fully agree.

You don’t see JBoss caring so much either.

My experience was different ;-)

Anyways, I agree with your last statement:

Anyways, have fun with this, and remember taking any one position to seriously is unhealthy.

Under whatever license we play it, I'm looking forward to our next match of poker or pool.

Alfresco Creates Activiti

Today, Alfresco launches a new open source project called Activiti (http://activiti.org) It's a open source Apache licensed BPM engine supporting BPMN 2.0 natively. We are very excited as we believe this project will be very disruptive in the BPM industry. Activiti will be run as a independent project. Me and Joram Barrez left Red Hat and joined Alfresco as employees to lead Activiti. We've assembled an impressive list of team members and companies involved over the last two months.

The first target of Activiti is to achieve the same developer friendliness that we established at jBPM. But this time, with the we have more liberal license, more companies involved and more resources. So we'll be able to build out very slick tools on top of the embeddable engine. A big thanks to the Alfresco UI designers for shaping the UI of these first alpha version.

Thanks to the Process Virtual Machine design, apart from BPMN 2.0, Activiti will also be able to support other process Domain Specific Languages (DSL). And because we're building it from the ground up, we can prepare it properly for the cloud as that has a profound impact on the design of a BPM engine.

Take a look at our website and the first alpha version that we also release today that includes several components and even a REST interface.

SpringSource is also excited to be part of the Activiti community. SpringSource is very interested in adding BPM capabilities to their stack. So they will help ensuring that this engine runs smoothly on the SpringSource stack. They will also contribute knowledge to run Activiti in the cloud.

Signavio is participating in the Activiti community by contributing a customized version of their leading web based BPMN modeler.

And Camunda brings a vast amount of experience with practical BPM implementations into the mix.

Together our ambition is to build the clear #1 BPM engine. And with this initial community, I am confident we'll be able to do exactly that.

Standalone BPM Is Dead

Standalone Business Process Management Systems (BPMS) have a big potential. A BPMS is aimed to simplify creation of software support for core business processes in an organization. For processes that are modeled on a business level, the automatically generated statistics provide for crucial business intelligence. That's all great.

But standalone BPM Systems have two main problems:

• High cost of setup. This implies getting the software up and running and also get all people up to speed with the technology.
• High cost of integrating the BPM system with the outside world. Web services or even specific adapters for communicating with other applications results in a significant threshold.

The result is that you need a big number of processes with high complexity for a standalone BPM system to pay off. I believe that is one of the main reasons why traditional standalone BPM remained a fragmented market with only niche players.

BPM should instead be offered where it's used.

Originally with jBPM, we focussed on developers. We provided BPM and workflow capabilities in the hands of the developers. We offered those feature in the world of the developer. Instead of requiring JTA to combine the application transaction with the BPM system transaction, we went a big step further. We offered the capability of the BPM system leveraging the transaction of the application itself whether that is Hibernate, Spring, EJB or anything else. Our next challenge in this respect is the cloud. Leveraging the cloud in the NoSQL interpretation of the word has a profound impact on some of the design decisions. The new project is build from the ground up with those new IT requirements in mind.

We embedded BPM into a developers world. It lowered the threshold to start using BPM and that opened up a new world of use cases for BPM. By making it so easy, even for small processes it becomes worth while to start using a BPM system. In our new project, we will certainly keep that focus on the developer and application embeddability.

With open source distribution and application embeddability we showed with jBPM that BPM can scale to a much more widespread adoption then any other individual BPM product had done before.

Enterprise Content Management (ECM) is another great use case for which it makes a lot of sense to offer the BPM capabilities where they are used. In the industry over the last 2 years you see more and more focus on bringing these worlds together. It makes a lot of sense.

An ECM system is a great environment where embedded BPM can lower investment to start collecting the fruits. Imagine a monthly meeting for which meeting minutes need to be reviewed and only after approval of the key attendees, the minutes need to be sent out to a wider audience. Would you setup a BPM system for that? I don't think so. But if that capability is offered inside the ECM system, then return on investment is instant. Again this is our strategy that will opens up BPM to scale far beyond it's typical niche.

With our new project we'll keep focus on the advanced processes capabilities. And we'll make sure that the runtime engine can be embedded easily in both the java world and in the ECM world.

Standalone BPM products that don't offer BPM where it's used are on a dead end in my opinion.