Do I hate BPM? No. I hate BPM Products.

by Robert Cooper

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"?>
<process
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:print="http://www.eclipse.org/tptp/choreography/2004/engine/Print"

<!--Hello World - my first ever BPEL program -->

<import importType="http://schemas.xmlsoap.org/wsdl/"
location="../../test_bucket/service_libraries/tptp_EnginePrinterPort.wsdl"
namespace="http://www.eclipse.org/tptp/choreography/2004/engine/Print" />

<partnerLinks>
<partnerLink name="printService"
partnerLinkType="print:printLink"
partnerRole="printService"/>
</partnerLinks>

<variables>
<variable name="hello_world"
messageType="print:PrintMessage" />
</variables>

<assign>
<copy>
<from><literal>Hello World</literal></from>
<to>$hello_world.value</to>
</copy>
</assign>

<invoke partnerLink="printService" operation="print" inputVariable="hello_world" />

</process>


So.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.

23 Comments

frank
2007-10-11 10:45:20
I couldn't agree more. I had a taste of BPM recently and I'm shocked that people actually do this for a living and consider it reasonable. It's unreal how much pain people are willing to go through for some perceived interoperability win. Adding insult to injury, the stuff almost never interoperates as advertised without additional pain.


Stupid is exactly the right word.

Derek Sunshine
2007-10-11 12:02:43
I have no idea what BPM stands for. Beats Per Minute? Do you have something against Techno music?
Falco
2007-10-11 12:45:36
Yep, couldn't agree more. I've looked into several BPM products (Jbpss BPM and others) and for the world I can't understand what these products truly offer above a "normal" regular Java programs. They introduce a layer of add-on bits that nobody really needs.
pete
2007-10-11 12:59:23
I have made several months worth of progress into the Oracle Fusion BPEL suite and as a language it totally sux. But you don't use the language, you use the UI. When it works it is very very very cool and beats me and my best Java hands down... And no, it isn't "writing" it's dragging and dropping and it is ultra fast and ultra clean. Of course that is very theoretical, we never got anything to work after about a man year of effort. No kidding.
Finally went and re-wrote it in Java from scrath using best practices and some unit testing and took a few man weeks. Ignore it at your peril though, this stuff will get the suits going hard and fast.
cooper
2007-10-11 13:07:28
Derek: "Business Process Management." Basically the idea is it represents the glue of the SOA world. You build discrete services, then you define your business rules ( Run credit check -> if credit > 700 do call this, else call that) into a simple orchestration file that, theoretically can change whenever management wants to alter the business cases.
cooper
2007-10-11 13:11:58
I can't understand what these products truly offer above a "normal" regular Java programs
There are some big advantages. One of the things I love is the long-lived process, where you can have extremely long asynchronous services that even break out into meatbody tasks (call a Background Check service, wait for user to enter data), and it will serialize out the execution process until the response comes back, then pick it up and start running again. THAT is something that is less than easy to do in Plain Java™. Yes, you could do it with a whole lot of event-based code, but in that case it is less clear than having a procedural definition in a simple rule file that the server can manage for you over extended periods of time.


Like I said at the top of this. I *love* the idea of these products. BPEL, on the other hand, is a bad joke, and I haven't seen a product that I really felt like I would want to use in an ongoing basis.

JAlexoid
2007-10-11 14:53:18
I do agree on the point.
BPEL should be not to define the process itself, but process elements. And XML is a stupid place to define any,and I mean ANY, logic.
C'mon... Use a steep learning curve language... Ruby can be expressive enough for that, and dynamic enough. Even JavaScript would be a better solution.
Brennan
2007-10-11 20:54:31
I spent several months working on a pre-BPEL 2.0 engine, and BPEL is not BPM. It is service orchestration. That said, I agree that XML is not a programming language, and was never meant to be. Trying to make it into one is perverse. So why are so many vendors latching onto BPEL as a workflow standard? Because it is the only thing that comes close to a widely accepted standard. We have JSRs for everything from content repositories to rules engines. Why not one for worklfow/BPM? BPM has the potential to be great, but no one has gotten there yet.
Patrick
2007-10-11 23:49:39
Problem is i guess most of the time you don't want a specific programming language in a bpm tool (at least that would be the tool's developer way of thinking). It's way harder to go from anything but xml to another language, while turning the above into working code by xsl or other means is actually quite simple.


The xml above could be turned into code for the next-ueber-language in 2030, when your ruby code might be obscure at best.


imho xml was never really meant to be read by humans - it was meant as an easier exchange format for machines. That aside, I have successfully modified XML files that where hard to read (OpenOffice files), the advantage of xml over a binary format is that you CAN (at all) modify these files. IF they have some kind of validation you can even modify them and hope they are still valid.


On a side note, I don't think MDA will ever really take of because I can't see that anyone could specify complex algorithms in graphs. A single line of code can easily represent a screen full of nodes in an UML tool.

RIQ
2007-10-12 06:00:09
I totally agree with the author. I especially find their sales pitch, that you don't need programmers to design and implement your processes, laughable. I've been working with a BMP suite for the past year and it's been the most unpleasant project that I've ever been on and I've been developing with Java for almost 10 years.
Garry
2007-10-12 09:36:24
Mega Dittos to the author!!!


Our management has forced us to work in the BPM world using the CapeClear suite of products. I have found the only way to get our applications deployed and running successfully is to build all the business logic into Java methods expose them as Web Services and then call them from the BPEL processes. The only logic I keep in the BPEL itself are simple XPath expression evaluations. Even after trying to keep the heavy lifting in Java, my BPEL processes can become bloated looking. Even the process of initializing and assigning variables is a very tedious task.

cooper
2007-10-12 10:29:33
The xml above could be turned into code for the next-ueber-language in 2030, when your ruby code might be obscure at best.


imho xml was never really meant to be read by humans - it was meant as an easier exchange format for machines. That aside, I have successfully modified XML files that where hard to read (OpenOffice files), the advantage of xml over a binary format is that you CAN (at all) modify these files. IF they have some kind of validation you can even modify them and hope they are still valid.



Patrick makes a fair point, but again, there is no reason for this to BE XML. You could certainly define a limited DSL that *is* both more human workable AND easy to compile into executable code in environments X, Y, and Z. To say imply because it is XML, BPEL isn't a "*specific* programming language" is disingenuous. BPEL is as different from VRML and Ant as C# is from Java. There is no reason you couldn't even define an AST for a BPM DSL then let every environment define their own specific parsables that best fit their environment.


Just to revisit my comment above... I LIKE what the BPM products (theoretically) DO, it is the HOW that makes them unworkable.

Miro
2007-10-12 10:46:45
I think you nailed it, Robert.


Using DSL based on some dynamic language is way more flexible, readable and leads to fewer errors than supposedly "universal" XML. Ruby is (as of now) probably best suited for the DSL implementation, because of the flexible syntax - just look the ActiveRecord or RSpec (none of them is BPM, but it nicely demonstrates the power of the near-human-language approach).

Gary S
2007-10-12 13:31:08
I've read, from Gartner, 90% BPM projects succeed, and the reason seems to be no matter how much of a mess is made of a BPM project it's still a vast improvement over legacy application silos.


People who write checks for multi-million $ BPM projects DO NOT want to hear the word programming. They want to hear that a Business Analyst can create the system so they get a sales pitch that shows wizard dialogs and a minute later a toy process is up and running. The check is written, and the guy who wrote it moves up the corporate pecking order.


People who program BPM projects DO NOT want to leverage the BPM tools. They want to hand code everything like they always have. This doubles or triples the coding for a project.


BPM, code generation, and MDA should be a programmers friend.

D
2007-10-12 16:51:39
People who program BPM projects DO NOT want to leverage the BPM tools. They want to hand code everything like they always have. This doubles or triples the coding for a project.


Actually I have personally found that timeline is a bit overexaggerated. There may be some initial ramp up coding for a project to be hand coded from scratch. If you are able to re-use those components on later projects they will be that much farther ahead. But I disagree with the 2-3 times the amount of time.
You also introduce another huge point of possible failure when you rely on yet another layer such as your BPEL Orchestration engine. Then you pile on the bloated looking BPEL code on top of that(even the GUI view of the BPEL steps are cryptic). There is no way in heck your Business Analyst could ever dream about "coding" any complex BPEL process without the major help of a low level programmer. Management has bought into the Buzz word of the week on this one, and the programmers are the ones paying dearly for their pipe dreams. Or maybe Gartner may have only polled the projects that were simple "Hello World" transactions.


Home grown frameworks that work are also much more flexible, instead of being handcuffed by whatever BPEL steps or functions your Engine will expose for you.

cooper
2007-10-13 15:09:43
People who program BPM projects DO NOT want to leverage the BPM tools. They want to hand code everything like they always have. This doubles or triples the coding for a project.


D made a good response to this, but I have to go two steps farther...


As noted above with long-lived processes, I would *love* to leverage the really great features some of the BPM tools provide, but to somehow say that even an (exaggerated) savings over "hand coding" means that somehow we should be OK with the complete crap that SURROUNDS these features is laughable. If you are making a software product, and any part of it is so loathsome to use that it inspires this kind of response, surely you should address this issue, not respond with "Sure, but it is only 6 months of misery!"


Seriously, someone makes a BPM tool that is pleasant to work with, and people will beat down their door. It isn't the category that programmers hate, it is the products themselves.

Carlos R.F.
2007-10-15 02:39:40
Well, if a language is based on XML then, this language is for graphical programming.
Because programming with a language based on XML in text-mode is very hard and unproductive (based on experiences)
In other hand, to understand BPM and its utility is necessary to have knowledge and experience designing software architectures (soa, for example). Not just be a java programmer.
Many people hates somes tecnologies because they dont understand it.


Alex Toussaint
2007-10-15 08:39:26
I would agree that if you are going to leverage a BPM tool, it better be able to clear define the contract between BPM and the rest of the project. The life-cycle needs to provide an environment for business users to do modeling - design the flow of the process, I don't believe there is an issue here. It should also provide well defined options to integrate with Java, and any other key technology required by back end systems such as SAP, .NET, etc. Coming from a Java centric background I believe this is where things tend to get problematic. Most of the modeling tools will provide a flavor or process flow definition that ends up being saved in XML - XPDL, BPEL, there are other custom formats. What you need is a good BPM engine that can take that definition and execute the flow making the proper calls to external systems. If your BPM engine has a good contract in place, the hand off is clear, and java developers are free to go build their best possible implementation to what is needed to complete the process. I am not saying this is perfect, but this is what is supposed to happen - there is a clear domain where BPM excel and there should be a clear contract to the Java world.
John Reynolds
2007-10-15 09:21:14
Hey Robert,


I am glad that you at least like the idea of BPM ;-)


BPEL isn't BPM, because it doesn't handle Human Centric services... The BPEL4People effort is attempting to address this, but I really haven't worked with it much.


As for XML languages, I agree with you there too... XML is a markup language, not a programming language.


So here's my obligatory retort... Do you think it's possible that BPM tools will mature to the point where you would use them, or is pursuing BPM a fool's errand?


Thanks for reading my blog,


John Reynolds

Brian E
2007-10-16 11:35:40
Bravo!! I couldn't agree more.


"All these unusable drag and drop tools ... are targeted to suits who can buy into the idea that some non-techy is going to orchestrate these services and modify business rules."


I won't detail my disdain for such tools, but in my experience, any productivity gains from such tools are completely lost in application maintenance and support.

Bhim Bomma
2007-10-16 21:23:36
I agree with author.


BPM is still under standardization process. But, it's not that its a new technology people just started using it. I don't know, is it because of "varing requiments in each domian/vertical" OR "just there is no shared knowledge of buisness process management".


But, how about having a Meta Framework (from open source community). It might just using existing open source tools/frameworks.

Guv
2007-11-02 11:00:34
I glad to see I'm not the only one who finds these tools useless. We recently wasted several months with some of IBM's offerings in this area. Never again.


The hard part is convincing management the the tool they spent tens of thousands will not do what they want, or worse, that a free tool is better.

jmond
2008-01-18 01:28:34
I got here from Google searching for "BPEL stupid". Thank you for making me feel less alone, now I'll go back to drowning in my little hell.