Is Standalone BPMS Really Dead?

No matter what kind of fancy gui or naming system create around a reprogrammable tool, the core skills required to use it are the same. If you intend to make business analysts into developers (e.g. Excel formulas) you might succeed. If you start out with the idea that you will build a tool that eliminates the need for 'development', you have already failed. Many have tried this before and they all ultimately fail. The reason is that the essence of programming is not knowing how to read and write code using esoteric languages. It's knowing how to turn the ideas in people's heads into computer instructions. Tools can affect efficiencies but will never remove the need for this skill. I believe this skill will become more common and a requirement for many more jobs.

Monolithic BPM has been dead for 5 years now, it's just that Tom has left the JBoss cave so he has been able to voice it. Successful processes are intimate yet flirtatious representations of the business use-case. To achieve that you need highly embeddable processes capable of consuming content, data and other processes at various points with little commitment to the consumable artifact itself, yet a very distinct definition of what to "do" with it when encountered. I think Tom has a good thing going here, I just wish it was tackled earlier. I am not sure how far he'll push the bar with the new gig, but I'll be watching.

A BPMS will not eliminate the necessity of development skills. However, good tools that make enterprise application development and support easier will always be in demand.

We use libraries all the time to make development easier. If a BPMS allows us to plug-in our code and does some heavy lifting for us, then why not use it in applications that can benefit from a BPMS. No need to re-invent the wheel to address things like: provisioning, maintenance, monitoring, administering, reporting, etc. A BPMS can provide these features while still allowing you to add your custom functionality.

Development skills are still required when using a BPMS, definitely, but if we can develop software components and tie them together using a BPMS, then it may often make sense to leverage a BPMS.

##

I think the broader problem with BPM acceptance (beyond standalone vs. embeddable) is that BPM is highly dependent on people across various departements of an organization. This is to be expected though, even getting everyone in an organization to use shared calendars is difficult. Involving people across departments makes it tough to BPM tackle in whole. However, breaking it into smaller parts, one way or another, can reduce the entry cost of BPM and make projects more successful.

Embedding BPM into an ECM application is a good example of using BPM to solve one piece of a big puzzle.

##

Our product, Flux, is interesting in that has a lot in common with a BPMS except with a focus on systematic processes rather than processes that involve humans. We have not witnessed a decrease in demand for system-to-system processes. I think this is where developers can benefit from a BPMS-like system to provide features such as: clustering, scalability, security, monitoring, application state, no single point of failure, etc.

Flux - Java Job Scheduler. File Transfer. Workflow.

A BPMS will not eliminate the necessity of development skills. However, good tools that make enterprise application development and support easier will always be in demand.

We use libraries all the time to make development easier. If a BPMS allows us to plug-in our code and does some heavy lifting for us, then why not use it in applications that can benefit from a BPMS. No need to re-invent the wheel to address things like: provisioning, maintenance, monitoring, administering, reporting, etc. A BPMS can provide these features while still allowing you to add your custom functionality.

Yea, I'm in agreement with you on everything. This is interesting stuff for me. I just wanted to elaborate on leveraging tools. Development is still development.

Tom's original post claims that the cost of BPM is too high. BPM is successful when used where it is needed. To me, that implies embedded in applications that require BPM features. I'm curious to see what Tom's project turns out to be though, it sounds like it may be focused on BPM for smaller teams rather than larger organizations.

Flux - Java Job Scheduler. File Transfer. Workflow.

Tom's original post claims that the cost of BPM is too high. BPM is successful when used where it is needed. To me, that implies embedded in applications that require BPM features. I'm curious to see what Tom's project turns out to be though, it sounds like it may be focused on BPM for smaller teams rather than larger organizations.

I think the time should have passed that BPM was aimed to remove developers. Who would put software produced by a non-technical business person into production? Facilitating collaboration between business analysts and developers is just one use case of BPM technology. There are also a lot of technical-only use cases for BPM.

For developers BPM languages like BPMN and jPDL provide a DSL for orchestrating asynchronous architectures. Instead of juggling with async messages, message handlers, setting and canceling timers, keeping track of the state of a process. All that can be easily expressed in a simple diagram (think state machine). The BPM system can then easily deal with messages and timers and call your POJO methods. And we also make sure that it integrates into your Java architecture.

regards, tom.

I think the point is that you shouldn't need programmers to define the process flow, or the business logic, or the business rules... and we ought to have business-usable tools to gather all of those requirements and frameworks that insure that those business-level requirements are respected.

Traditional programmers have the skills to handle integrations, etc... and I don't see them going away any time soon... but for most business applications they need to operate within the confines of a business-centric architecture rather than building things up from scratch - it's simply too expensive, and quite frankly a waste of time and effort.

The trick is to come up with tools and environments that help each audience supply their part of the puzzle in the most efficient and timely manner.

Tom,
I am not for removing developers from the process creation (this is how I/we earn living at the end of the day). I am against treating BPM as development DSL (although I do not consider BPMN a DSL). I think the best usage for BPM is to allow business analysts to design processes and developers to implement them. I do believe that no one of these groups in separation can solve BPM implementation problems and they need to work closely together. That is why I am advocating BPM tools which have a natural support for both groups and allow business analysts to model and simulate processes without learning programming language or developer's tools (they do not like Eclipse) and developers to implement them correctly and easier - minimizing "juggling with async messages, message handlers, setting and canceling timers, keeping track of the state of a process."

The trick is to come up with tools and environments that help each audience supply their part of the puzzle in the most efficient and timely manner.