First SOA was proclaimed dead and now Tom Baeyens, the founder of jBPM, is coming up with a new obituary - this time for Standalone Business Process Management Systems (BPMS). According to Baeyens, standalone BPMS 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.
That means that in order to justify their usage it is typically necessary to implement a significant amount of complex business processes, which is not always simple, due to required BPM maturity of the enterprise. As a result, usage of BPMS creates a very expensive entry point for a BPM implementation.
Baeyens’ solution to this problem is to offer a business process platform where it is mostly used. The example of such approach is jBPM:
Originally with jBPM, we focused on developers. We provided BPM and workflow capabilities in the hands of the developers. We offered those feature in the world of the developer.
The jBPM framework can be used to either build an application embedding business process (es) or to be extended to get a full-fledged BPMS.
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 worthwhile to start using a BPM system... With open source distribution and application embeddability we showed with jBPM that BPM can scale to a much more widespread adoption than any other individual BPM product had done before.
Another example offered by Baeyens of using BPMS as a foundation for application implementation is that of Enterprise Content Management (ECM) systems:
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.
It’s hard to argue with Baeyens that an entry point to a BPM implementation has to be lowered. It is also true that jBPM is a great framework. The real question is whether BPM is a tool for developers. There are definitely situations when BPM can be used as a high-level development language, but the real power of BPM, especially when it is used together with SOA, is its ability to break application’s boundaries and implement enterprise-wide business processes. And at this point, true BPMS, providing not only an execution environment, but also modeling, simulation and BAM support, start to really shine.
Community comments
Development is development is development
by James Watson,
Re: Development is development is development
by Eric Rich,
Re: Development is development is development
by James Watson,
Re: Development is development is development
by Eric Rich,
Re: Development is development is development
by James Watson,
Yawn.
by Zubin Wadia,
The real BPM features for developers
by Tom Baeyens,
Re: The real BPM features for developers
by John Reynolds,
Re: The real BPM features for developers
by Boris Lublinsky,
Re: The real BPM features for developers
by Boris Lublinsky,
Development is development is development
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Yawn.
by Zubin Wadia,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Development is development is development
by Eric Rich,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Development is development is development
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I completely agree with all of this. There are many tools designed for various tasks. My point is that programming with a BPMS is just much programming as is programming in (e.g.) Java. Is programming in Java harder? Maybe, maybe not. It depends on what you need to do. I find it's often best to use a narrowly scoped tools for the majority of my work and use something more general purpose for filling in the gaps. Sometimes I find it's easiest (quickest and cheapest) to build my own narrowly scoped tools.
In the interview there are comments about how the BPMS was directed at developers. This appears to be contrasted against the new approach. I read that to say that the new audience is non-developers.
There's a very widely held fantasy with a lot of IT management that if a tool isn't primarily text based, using it is not programming. I believe this not only completely incorrect but that it is extremely dangerous. I've seen many cases where tools directed at non-developers are ultimately handed over to developers who hate these tools not designed for them.
There's nothing revolutionary in what I am saying. Albert Brooks wrote his "No Silver Bullet" essay a long time ago and nothing has changed to invalidate it. Vendors who sell software tools claiming that they eliminate 'programming' or the need for 'developers' are either cynically preying on the misconceptions of their customers or are delusional.
Re: Development is development is development
by Eric Rich,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Development is development is development
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Based on my understanding of what BPM is, I would expect it to be expensive. Figuring out what the business rules is always expensive. The programming (regardless of the tools) is relatively cheap.
I've personally come to the conclusion that this is the reason that this is why businesses are generally unhappy with tools that are supposed to make SOA and BPM etc faster and easier. Most of the time and effort is not technical. Roughly, let's say it's something like 90% specification and 10% implementation. So even if the tools reduce the implementation costs by 90%, you are only going to get a savings of 9% overall.
This is what makes it so tempting to put the tools in the hands of the business. If we could somehow eliminate the need to extract and document the requirements, you could get some real savings. The flaw in this thinking is that the reason that it's so hard to get the requirements is that the people who know the business logic don't think like developers. Getting them to explicitly lay out every detail is hard work. The computer isn't going to ask for clarification or challenge what it's told.
In the Ralph Johnson presentation on this site (recommended) he has a side note about how software projects are named based on their goals and not based on what they achieve. He then goes on to say that people on the outside (especially non-programmers) don't understand this. I think there may be something to that.
The real BPM features for developers
by Tom Baeyens,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: The real BPM features for developers
by John Reynolds,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: The real BPM features for developers
by Boris Lublinsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
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."
Re: The real BPM features for developers
by Boris Lublinsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks John,
my point exactly