Skip to main content

Why do Java developers hate BPM?

Posted by johnreynolds on October 10, 2007 at 4:40 AM PDT

Java developers hate BPM.

The preceding sentence is (of course) intentionally tailored to be controversial. People tend to read controversial blogs, and I'd like you to read this one. Now that I have hopefully grabbed your attention I'll tone it down a bit...

A lot of Java developers hate having to use BPM tools instead of the object oriented tools that they are comfortable with.
I work on a lot of BPM projects, and I work with a lot of other folks who work on a lot of BPM projects, and we have all encountered resistance from traditional Java developers. Java developers (in general) would rather use frameworks like Struts and Spring than be saddled with the constraints of a BPM suite.

Java frameworks like Struts and Spring are in the background... they provide just enough support to "set your creativity free" so that you can be a real programmer. 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.

BPM suites are in-your-face. They rob you of your creativity. They 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... Fortunately most Business People are too intimidated to use these tools, but it does open the door for them to look over our shoulders and meddle in our affairs.

That certainly doesn't sound like something that real programmers would like, does it?

I'm not being subtle, am I?

BPM suites are a threat to traditional Java programmers. These suites are far from perfect, but even in their current state we can see where things are heading. The days of the Java Guru as indispensable are fading... 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... programming isn't as hard as it used to be... and that's going to cost us.

That's why Java developers hate BPM.


(cross-posted at Thoughtful Programmer)

Related Topics >>

Comments

 I take issue with several of your points: 1. ...

I take issue with several of your points:

1. Good programmers are open, collaborative, and engaging. The coop their business counterparts whenever and whenever possible.

2. Spring and Struts are about as sexy and agile as two octegenarian's on valentine's day.

3. We should write tools that make us obsolete. See the Virtues of a Programmer(www.hhhh.org/wiml/virtues.html). When we start building little forts and worrying about coding ourselves out of a job we cease being the type of people that should be programmers. As a Software Engineer approaching the middle of his career, I often hear older programmers complaing about how the youngest spend long hours at thier desks and produce solutions that mean the company needs less programmers. Thats people being passionate and innovative, when did this become a sin?

4. BPM Sucks not because it makes us obsolete or gives visibility into what we do. It sucks because its ineffective. It makes you less productive. Often programmers are forced to use these tools because non-programmers put their reputations on the line and paid for the licensing fees. Its the cardinal sin of the business person ... telling a programmer how to program. Its the easiest way to thrust your best and brightest into the loving arms of a startup and leave you with a crew of people worried that BPM is going to take their job.

Why do Java developers hate

So, you think you made a fine point by saying that Java-delopers hate new technologies because it makes them obsolete?
Well, they don't hate BPEL for THAT! They hate it, because it is simply does NOT provide a productive way of working.
Now it is 2010, and the biggest software company in the world is still not able to deliver a decent product that just works. Have you ever tried to
write a non-trivial BPEL-Process in SOASuite 11g? Have you ever tried testing your processes and move them from development
to test and then into production? You still have to handcode these things. You have to use things abstract WSDLs so that
all of your processes are started correctly when you reboot the server. And this is not well-known and of course not
documented. If you change the WSDLs in your processes, it is in most cases easier to REWRITE THE WHOLE THING FROM SCRATCH,
because of all this automatic namespace generation from JDeveloper - things just do not fit anymore.
And no, business analysts will never be able to implement these processes themselves. You need a (good!) developer that
can solve all the highly technical errors that will crop up once they try to make simple and obvious modifications.
I cannot imagine how a business-user makes sense of the graphical representation of a BPEL-process. That is just not
possible. Even in principle. There have been numerous attempts in the past to establish graphical programming, and
they all have failed for all but the simplest tasks. It is actually quite arrogant to assume that BPEL has finally accomplished this goal. Your post is three years old, and we are still not there.
As a programmer, I always choose whatever technology REDUCES my work! But with BPEL, I have MORE work producing the same output
as before, and it is MORE expensive to change anything later. And nobody can do this work but me, the programmer.
If it worked, I would embrace it. But it does not!
THAT is why I hate BPEL!

Use BPM simply as additional components

The Imixs Workflow Project focus on a different kind of usage. The Imixs JEE Workflow provides Java EE components (EJBs and JPA) to be used in any Java Enterprise project. These components fit into the component model of Java EE and provide usefull functions from a BPM framework.
The Imixs Workflow is not a BPM Suite but it enables developers to implement their BPM solutions in a much faster way.
Read more about the Open Source Project Imixs BPM

Completely disagree

First, I don't hate BPM - it's a good tool for a good purpose - documenting and illustrating business processes. It's not - however - a development tool. BPM tools simply don't handle the things programmers do:
  • Data validation
  • Error handling
  • Other Component Failures (retries, graceful degradation of service, etc.)
  • Performance enhancements
  • Designing for failover, redunancy, and latency
  • Deployment concerns (versioning, beta rollouts, backward compatibility, etc.)
  • Monitoring, logging, and troublshooting
The fact is business analysts don't deal with these concerns. And, when the app is slow, there's no "Make it Faster" button in the BPM to push. My 2 cents...

I think you need to check out "other" BPM suites

 Thanks for the comment Jason... This post is a few years out-of-date.  BPM tools have really matured quickly.

Teamworks 7 - from Lombardi - an IBM Company - handles everything you mention.  I'd have to agree with most of your list back when I posted this, but not any more.