Summary
A great deal of research and product development effort has been invested in business process modeling (BPM) tools by software vendors over the past decade. But are BPM tools really useful to developers?
Advertisement
Business process modeling and related activities have been the focus of many tool vendors over the past several years: Java standards, such as the Java Business Integration API (JSRs 208 and 311), as well as Web services orchestration tools and even enterprise workflow management systems, all aim to make it easier for developers and business managers to tie together disparate business processes.
Yet, when it comes to integrating enterprise systems, developers still prefer to pull out their traditional developer tools and programming languages instead of using higher-level BPM tools. At least that's the basic thesis of a pair of recent blog posts by John Reynolds and Robert Cooper in Why do Java developers hate BPM? and Do I hate BPM? No. I hate BPM Products.
Reynolds notes that:
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.
In response to Reynolds, Cooper observes that:
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.
What do you think of BPM tools? Do you think they can be useful to developers? Do you use BPM tools in your projects?
As the author of the "Do I hate BPM? No. I hate BPM Products" post, I want to state that while I think the excerpting here is a fair assessment of the arguments, I am not arguing that the *features* of BPM products are bad. I think if you read the comments and OJ, this is clear. What I *am* saying is two fold:
1: As summarized above, the idea that process and service orchestration will be done by non-programmers is a fallacy.
2: The current crop of BPM products, while they include compelling features are so unpleasant to use, that they evoke this hatred of BPM. It isn't BPM that developers hate, it is that no one has delivered a really compelling product, and it taints the concept.
I think BPM tools are useful to business not to the developers. There are less ways to make BPM tools interesting for developers unless they (developers) are allowed to craft one for them to use :).
As Robert's arch nemisis on this topic, I can only say that he's got some great points in his blog, and I vehemently agree that XML is a lousey basis for a programming language: thoughtfulprogrammer.blogspot.com/2007/08/xml-is-markup-language-duh-john.html
BPEL isn't BPM.
I don't disagree that BPM tools are immature... but I think they hold great promise.<p>My concern is that Java developers don't give them a fair shake... It's one thing to be bitter after using a flawed tool, it's another to approach it with disdain on the first day of a training class.
I'm going to have to go with Robert here. This idea that developers don't want to use drag and drop tools because it's boring is a load of crap. It's basically an ad hominem argument. Sure, we all know a Mel that no matter how much you explain how a new tool will help them they still want to program in assembly. But those are the exceptions. Most programmers are busy and if a tool can save them time and headaches they will use it.
I've used a good number of tools that were developed for non-programmers. Here's the cycle:
1. The salespeople tell some suckers that they won't need developers anymore. Many lies are told. 2. The company bites. They might even layoff some developers. 3. Non-developers try to create their own programs with 'simple' drag and drop tools. 4. Complete meltdown ensues when the first bump brings the house-of-cards crashing down. 5. The developers are now told to use this tool to do their work and maintain the steaming pile that has been built. (a.k.a throwing good money after bad.) 6. The developers try to maintain the mess that the non-developers wrote and create maintainable software without the tools that developers normally use (because they work.) 7. Productivity and/or quality continue to suffer. Developer morale drops. Much more 'code' is created than would be needed in conventional development approaches. 8. "Experts" in the tool are contracted and/or hired at great expense. They teach the developers how to work around all of the product's deficiencies in order to be moderately productive. 9. The rising expenses cause managers to look for ways to reduce development staff. Outsourcing may be used. 10. A vendor comes in to tell some suckers that developers won't be needed with their new dap and drop tool...
Any developer who has been through this is going to be pretty skeptical of a new gui-based tool. And it won't take long to see where the pain-points will materialize.
I'd also like to add that I think GUIs can be really helpful. The problem is not the GUI, it's the 'tool for non-developers' that is the issue. These tools always end-up being pushed on the developers but were never designed for developers. Good GUI enabled tools for developers are the exception and that's probably because the tool makers are busy chasing after the mirage of developer-free development.
Writing code is really one of the easier tasks of a developer. A drag and drop tool is an incremental improvement (when it's an improvement at all) not a revolution. The really hard work is unchanged.
They suck. They only take useful time from programmers' hands.
"Do you think they can be useful to developers?"
No. The amount of time it takes to use BPM tools for any practical outcome is too big.
"Do you use BPM tools in your projects?"
We have tried in our company, but it only proved that these tools are useless.
The only useful and practical thing to do is to write an SRS (software requirements specification) which is useful for the client, the managers and the developers, and which might include business process diagrams.
I don't have a broad experience with BPM - just vendor presentations and such. I have lots of concerns about the tools I've seen and the way they work.
First, it does seem the target audience are business people and the selling point seems to be that with BPM you can take back control of your business. This makes sense from a vendor prospective: find the motivation and the money, and sell to that. Of course it sets up a conflict within the company.
Second, the BPM tools I've seen are not very complete. They clearly only handle the common cases and only work with the vendor's stack.
Third, it seems to adopt a BPM tool you've got to drink all the Kool-aid. You live and die with the vendor's stack. The stacks I've seen are weak and incomplete.
Fourth, the abstraction level is so high you have no idea what's going on, and no control when you need it. How can an IT department allow critical business processes to be implemented in such a fashion? There's no room for making architectural trade offs.
Fifth, BPM adoption can set up conflicts within a company. IT is held responsible for the software non-programmers 'develop' using BPM. When the s**t hits the fan who is going to be asked to make it right? Who is capable of making it right?
Looking at the positive, I would love for our business side to have a MODELING tool that they could use to express to IT what our business does and what it ought to do. I think models are great for communicating across organizational and expertise boundaries.
I don't think having IT use BPM addresses all of my concerns. We've seen the over-abstraction problem in many forms over the last few decades. The vendors couldn't sell it to developers so now they target the business. The whole enterprise software marketplace now is about snake oil and "marketecture."
Previous Topic
