John Raynolds asked recently the question: "Why do java developers hate BPM?"
From his experience and the one from others, he concludes:
BPM suites [...] rob you of your creativity [and] dictate to you how you will develop your application. BPM suites make programming boring. They force you to use point-and-click and drag-and-drop tools to design your process diagrams, data models and forms.
What's worse, they actually encourage Business People to model processes and design forms on their own...
He argues that:
Java developers (in general) would rather use frameworks like Struts and Spring than be saddled with the constraints of a BPM suite...You can build almost anything with Spring or Struts (if you've already mastered the intricacies of Java). They are light-weight, they're agile, and they look sexy on your resume.
We've used Java to build tools that make knowing Java itself less important, and that's opened up competition for us from folks who didn't spend years learning Java.
We're victims of our own success... and that's going to cost us.
That's why Java developers hate BPM.
Readers expressed different reasons too. This reader for instance hates BPM because:
I can't honestly see where BPM would ever be a practical tool to get something done.. - NetBeans has a free BPM tool, but it just looks like a simple Web Service automation tool. That is completely useless to the business requirements and concerns that I encounter. Even the more fancy tools sound like fancy high level process scripting tools which still don't offer much value. - None of the good BPM suites are freely available to devs so it's hard to experiment. They cost a lot of money and my boss isn't buying them.
Where are the success stories? My ears are open: show me some real world applications of this technology.
Another one argues that:
We hate BPM cause we shouldn't be using it. BPM 's [...] idea is that Business People do the modeling task, but due to the fact that Business People don't use it, we end [up] doing it.
This reader does not buy into the apparent simplicity of "point-click-and-run" as often advertized:
The reality is that even given the most simple of processes, those processes actually run on a computer. And the computer ... only understands "do what I say", not "do what I mean".
No matter what the diagrams wireframe says, there has to be a fundamental understanding of the realities that those little blocks it's wiring together represent. There are a LOT of very subtle details contained within that "Post Invoice" bubble, and try as we may, those subtleties WILL stick out and affect those around them.
In the end, the folks that need to create those diagrams need to understand computers and computing. These folks ARE programmers, and programming requires a specific kind of mindset as well as technical knowledge.
...So, while it may only show up as a single box on the diagram, you really had better have a good idea what's happening in those "100 lines of J2EE code". The complexity is still there, no matter the color or shape of the little box.
As a developer, I ... puzzle as to "when does my system become big enough that's it's worth throwing this blob of infrastructure in the middle of it all -- that I need a scripting language interpreter and runtime that needs 1GB of RAM all for itself".
Obviously abstractions have made all of our lives better in the long term over time. From binary codes to assembler mnemonics to C to Java. "One line of Java represents 10 Java Byte codes which represents 100 machine language instructions.". But the best Java programmers have a good idea what those 100 machine instructions are doing. And the novice programmers are at times punished by their ignorance of them.
Robert Perkins who has worked with BPM tools explains the reason why he dislikes BPM suites:
Go ask you engineers to write the next release of your product as a flowchart in a visio-like tool. They will be limited to using javascript. They will have no access to an automated regression testing system . They will have none of the features of eclipse or Intellij Idea they have come to rely on. There will be no build deployment scripts, deployment will involve copying files manually. Oh, and they will not have version control.
You insinuate that developers want to use these tools for selfish reasons, rather than using the tool or product which creates the most value for the business.
There's some truth to that. I think that many non-technical businesses have come to believe this, creating distrust between the developers and the business side. I know my last company had this problem and I imagine lots of vendors and sales teams exploit this.
Also, as far as success stories go, I don't know how much faith I'd put it them. My company was listed as a ''success story'. The reality was that the project was a disaster, the end users were up in arms, and as of last march the entire development team had moved on.
The question is more general than just BPM. There are many places where the business could be the best positioned to personalize some business or presentation logic. Recently Mark Proctor raised the question of the benefit of a unified Rules and Process Engine, arguing that many process definitions require the expressive power of a rules engine and that rules could benefit from the state management capabilities of a process engine. Mark adds:
One of the beauties of a unified modelling environment is you get to choose how you want to model things.
Dave Wright sees that everything is inextricably linked:
one could say that rules and data are are more tightly linked than rules and process, given the similarity of data models and terms & facts models. I know you don’t want separate process and rule platforms, do you want to get rid of separate data platforms as well?
This is confirmed by Pierre Bonnet's analysis on Agility Chain Management Systems (ACMS) who sees a strong connection between MDM, BRMS and BPMS:
- Master Data Management (MDM). Streamline management of reference data and parameters, allow implementation of service configuration models to contextualize execution.
- Business Rules Management System (BRMS). Rules rely on reference data and parameters. Pre and post-conditions of organizational services are located in the rules management system.
- Business Process Management (BPM). Processes use the rules to drive the different stages of activities. Orchestrated services are contextualized by the MDM and the BRMS.
Peter Evans-Greenwood argues for a new approach to define application semantics:
The separation between rules and process is just an artifact of where the technologies came from, and not where we want them to be. Having separate rules and process engines creates a huge amount of overhead that we can better do without.
A more fruitful approach might be to come at the problem from the opposite direction. Let’s go top down, investigate how people understand and process business logic, and then create tools and techniques which mimic our approach.
