BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Why do Java developers hate BPM?

Why do Java developers hate BPM?

Bookmarks

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • We need more than just Workflow to make this tech useful

    by Mark Proctor,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We've got a long way to go yet, but I'm hoping that we can make processes sexy again, as discussed in this blog:
    blog.athico.com/2007/11/vision-for-unified-rule...
    Which was also featured in this infoq article:
    www.infoq.com/news/2007/11/rulesprocess

    We are trying to build a platform where processes and rules are first class citizens in a unified and fully integrated platform. While this can be used in web like situations, my real aim is for declarative complex behaviour modelling - I think once we can get enough power into the process and rules modelling metaphores we'll make something that java developers might actually want to use for their business logic. The key thing is we aren't trying to dumb things down for business users, we are trying to build a rich and expressive environment for java developers. The other area we are researching is Event Stream Process/Complex Event Processing, and we hope to be adding that to our platform soon too.

    Mark
    blog.athico.com The Drools Blog

  • Re: We need more than just Workflow to make this tech useful

    by Jeroen van Bergen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The key thing is we aren't trying to dumb things down for business users, we are trying to build a rich and expressive environment for java developers.


    I think that is a very good attitude. My feeling is that a lot of developers are used to the freedom that is offered by a genaral programming language such as Java. People accustomed to that freedom will fidget at the restrictions that are part of the current BPM offerings.

    As noted in the article, a lot is going on behind the colourful boxes and lines that are presented in a modelling tool. Having a good understanding of what is going on behind this presentation layer will yield better applications. One of the problems that need to be solved is how to isolate the business user from potential technical problems so they will not be able to create crippled systems. The big question is how to do this.

    An analogy: MS Access is a very powerful tool for a lot of end users. It enables them to quickly create working applications with relatively little effort or programming knowledge. However, these applications are not suited for a lot of concurrent users or large datasets. These limitations are not very apparent to the business user, but are almost invariably something for an IT department to work around.

    I'm wondering how well these tools are suited for their intended purpose. Rolling out new processes in big companies is not trivial, yet these tools are usually positioned as a kind of 'MS Access for business processes'.

  • Re: We need more than just Workflow to make this tech useful

    by Mark Proctor,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I just did a new blog showing the process stuff leverage the pluggeable Dialects for actions that Drools already has, includes a nice screenshot too :)
    Pluggable Dialects for Drools Processes now work :)

  • Levels of abstraction

    by Gavin Terrill,

    Your message is awaiting moderation. Thank you for participating in the discussion.


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


    Good point, but why stop at Java? To me, BPM works at a higher level of abstraction than the coding layer. I tend to think of the workflow layer as the glue that coordinates services.

  • Re: Levels of abstraction

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Gavin:

    I did not find any comment who was really critizing the level of abstraction. Most of the comments are focused on
    a) the lack of development environment features (versioning, testing...)
    b) the difficulties of bring the business into the development cycle
    c) Some might view the current abstractions as a bit immature

    this is very encouraging, there seem to be a strong reflection on how we build information systems that has started.

    JJ-

  • I thought the same

    by Bill Burke,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I thought the same of BPM. That it was nothing more than XML scripting and the dumbing down of developers. Until I actually started looking into BPM frameworks like jBPM, I didn't see the value add these frameworks had to offer. When I started thinking of jBPM as a reliable and fault tolerant state machine I really started to see the potential for BPM frameworks. Then when you start combining the use of transaction management and compensations with your business processes, you have some real nice abstractions to work with as you develop your applications.

    The key is, IMO, is to avoid coding in XML and focus solely on the value-add of these BPM frameworks.

    --
    Bill Burke
    bill.burkecentral.com

  • Re: I thought the same

    by Stefan Tilkov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The key point is that most BPM tools I am aware of aim to impress management instead of actually providing value to developers (and I strongly agree with the point of view that BPM at a level that can be executed is programming, so developers are required). As long as there is no support for unit and integration testing, reuse through modularization, encapsulation, namespacing/scoping, version control etc. etc. none of the tools can compete with any reasonable programming language in the real world. In addition, no reasonable scenario can rely on a central engine to drive everything -- i.e., I wish more tools were available as libraries instead of as engines executing a program that needs to be created visually (and can only be exported to some half-baked, semi-standardized textual language).

  • Re: We need more than just Workflow to make this tech useful

    by Steven Devijver,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One of the problems that need to be solved is how to isolate the business user from potential technical problems so they will not be able to create crippled systems. The big question is how to do this.


    You can't solve this for the simple reason that only humans can judge if a process is correctly implemented. The details become very complicated very quickly so that any automatic checks can't validate your diagrams against your intentions.

    What BPM tools like the one in NetBeans tries to do is hide complexity. If you rely on these tools you're denying there is complexity. And it will haunt you.

    BPM is just a replacement for writing parts of applications. It doesn't do anything to solve all the other problems.

    You can create some applications with BPM tools but certainly not all of them. The question then becomes: in which category belongs my application?

  • Re: Levels of abstraction

    by Gavin Terrill,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I guess I was trying to say that being able to operate at a higher level of abstraction (i.e. workflow) is a good thing, used appropriately of course. "If all you have is a hammer then everything looks like a nail." While Java is certainly an excellent hammer, a good architect has many tools at her disposal.

    For example, it would not be appropriate to implement controller logic using a BPM product. It could be done I suppose, but for all the reasons folks have mentioned here, it probably shouldn't.

    On the other hand, if you look at something like Sagitta 2000 (PDF), a large IT system built for Dutch Customs to process customs declarations, you can see that workflow has been used to coordinate the overall process, including integration with numerous back end services and managing tasks for the human "services". As Bill says, it is basically being used as a "reliable and fault tolerant" state machine.

    Stefan brings up an interesting point wrt testing, however given that the level of abstraction is different, I'm not sure we are comparing apples to oranges when we discuss unit testing. Perhaps model verification is something to think about - Will Van de Aalst wrote about this and why it was important when making their selection of workflow engine for the Sagitta project.

  • Re: Levels of abstraction

    by Steven Devijver,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It's not so hard to come up with litmus tests for BPM engines. Here's one example:

    Send messages in a queue to a web service. Retry messages that fail x number of times (x has to be configurable). After x failures give up and remove the message from the queue IF an alarm can be successfully raised.


    This is a pretty basic requirement. I'm sure a lot of BPM engines will not be able to cope with this unless you write you're own implementation.

  • Why do Java developers "WILL LOVE" BPM?

    by Miguel Valdes Faura,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is main reason why last year we decided (BUll/OW2 and Jboss/RedHat) to join forces and work on something new: The Process Virtual Machine

    To solve common BPM solutions issues:

    - Monolithic Workflow and BPM solutions


    • « black box » based products

    • Web application environment must be the one proposed by the editor

    • Not easy to directly deal with the Workflow/BPM API’s

    • Complex to deploy, test, and couple workflow transactions with application transactions


    - Fragmentation around process definition languages: XPDL, BPEL, BPDM…
    • One single, fixed process language

    • Lack of mindshare


    - Sole focus on the business analyst
    • Collaboration between analysts and developers is ignored !

    • "Zero Code" BPM development



      • I've even posted at the BPMCorner community about this issue and our solution last week :-)

    • Ummm, not quite so (or more accurately that's a load of fail)

      by gcom nz,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Coming late to the game, but just correcting some of Stefan's notions here for future readers. Stefan implies that BPMs don't facilitate unit and integration testing, namespacing, modularization, distributed execution, need to be created visually and so forth, when in actuality a quick look at jBPM would show you that all of the above aren't just covered, but are highly integrated features and capabilities, and more importantly, are not at all half-baked. And yes, there's a lot of craptacular management-friendly advertripe out there, but that's pretty normal for most technology, or at least anything Oracle touches ;-)

      Stefan, it helps to know something about what you're commenting on, otherwise you just look silly. I hope you have higher self-standards in your diatribes about anything that's not REST, heh.

    • Because we are used BPM-s which does not solve our problems

      by Armen Arzumanyan,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Because we are used BPM-s which does not solve our problems. I think if we meet Pegasystems or Appian BPM we should love BPM-s.

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    BT