John Reynolds has a post at Java.net entitled Why do Java developers hate BPM? where I think he completely misses the problem with “BPM” products:
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.
Let me be clear from the outset here. I *love* the idea of BPM tools. I like the idea of a standard process set and ruleset that is clear and standardized. I am not even opposed to something “dictating” how I will build my application. First, constraints encourage creativity more than they limit it. Second, this gets to the “Software Engineering” goal we have talked about for three decades of standardizing parts and interactions into systems that sidestep common errors. From design patterns to frameworks this is the goal.
Here is the problem:
XML is not a programming language.
Let me say it again.
XML is NOT a programming language.
Now I worked for a company what seems like eons ago now, and we made this mistake. We spent a ton of time working on an interpreted XML-based language for our system, and it worked, but it was never usable. XML is great for data. It is good for basic programming that is simply declarative in nature. It is horrible as a format for writing process or algorithms. All these idiotic drag-and-drop program with graphics BPEL tools are impossible to use for anything of significant complexity. BPEL itself is so verbose as to obfuscate any logic you need.
Now, I am not saying that BPM tools should have a general purpose programming language, but even using a *subset* of Groovy, Ruby or Java would be much easier to work with… For programmers…
And here is where it breaks down. All these unusable drag and drop tools, and “easy” XML programming languages aren’t targeted at programmers. They are targeted to suits who can buy into the idea that some non-techy is going to orchestrate these services and modify business rules. These products are unworkable because they are based on the idea that “You won’t need programmers anymore!” at least at a core level. Once you make that assumption you start building things that get in programmers way, and still include enough abstract programming concepts that no non-programmer is ever going to be able to work with it proficiently.
Just to emphasize this point:
<?xml version="1.0" encoding="UTF-8"?>
<!--Hello World - my first ever BPEL program -->
<invoke partnerLink="printService" operation="print" inputVariable="hello_world" />
PrintMessage hello = new PrintMessage(); hello.value = "Hello Wolrd"; PrintService.print( hello ); is now incredibly long and non obvious. Scale that up to something where you have to do complex data adaptation and handle exceptions across multiple service calls, and you should be able to see how stupid this gets.