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.