Tuesday, 11 May 2010

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.

First... I am delighted by your new project, and I am sure it will be great.

But I am going to have to disagree with you about the death of standalone Tom... There is clearly a strong case for embedded BPM whenever you are building products that embed process - but that's not the common use case that I experience in my practice. In my practice the Process is the driver of the application and the standalone BPM development environment is the key to success.

I think your approach is going to be great for a huge number of applications, but not for the type that I usually work on.

Your new embedded approach is going to be much better for professional developers, and based on recent developments the "standalone BPM" approach is getting much better for occasional/business programmers.

Are you proposing a BPM system where processes are managed and performed by services, kind of rest interface, which is the approach of CouchDB? Isn't it a good problem to be solved by Erlang, since there is a lot of parallelism and scalability involved? Is Java still appropriate for this kind of problem?

@John Reynolds I have not yet formed a detailed opinion but that "Process Manager to Process Manager interaction" might become more important with a more universal acceptance of BPMN 2.0. Such interactions could involve processes within more than one organisation.

About Me

I'm founder and CEO of Effektif and on a quest to simplify process management and collaboration on the cloud. Before Effektif, I founded the open source BPM engines jBPM and Activiti. In this blog I share my thoughts on processes, collaboration and how those match on the cloud.