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.
100% d'accord ! Thats why we where in 2003 attracted about jBPM. Respect to your upgright position and the consequences taken.
ReplyDeleteThere is great potential, that your new project will change the bpm scene again!
The next-level-integration.com development team is happy to make a serious contribution to the new project.
Our b2bbp.org provisioning platform for industry practices will take advantage of such an embedded BPMN engine!
Stefan
Thanks, Stefan. Great to have you on board!
ReplyDeleteFirst... I am delighted by your new project, and I am sure it will be great.
ReplyDeleteBut 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.
I see a bright future for both.
Hi John,
ReplyDeleteIn the content of the article, I sketch out that embedded usage (both in enterprise apps and ECM) can expand greatly the use case of BPM systems.
With that I did not say that the stand alone BPM use case doesn't make any sense. On the contrary, in the intro I try to explain that BPM standalone already makes sense.
But I believe that BPM engines that only can be used for standalone BPM will be surpassed by engines that can serve both the standalone use case and all the embedded use cases as well.
OK i admit... i picked a catchy title to make you read it. That was maybe stretching it. But hey, it worked! you read it ;-)
I hope that I clarified my point more clearly now.
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?
ReplyDeleteThanks for the clarification Tom... Now it makes perfect sense to me.
ReplyDelete"Standalone" should really use the same embedded Process Manager API as everyone else.
As I blogged awhile back, I think deep Process Manager to Process Manager interaction is going to become a must have, and your efforts are key to accomplishing that.
@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.
ReplyDeleteI think any standalone software system is dead now. The reason is that enterprise system like ERP covers a lot of ground and you can put so many software modules on top of it.
ReplyDelete