BPMS or just programming?

Question

What do you prefer (from the developer's point of view) when it comes to implementing a business process?

A business process management system (BPMS) or just your favorite IDE with the necessary tools and frameworks (for example, a reporting tool)?

What do you think is the biggest advantage of BPMS compared to the IDE with your personal tools and frameworks?

OK Maybe I should be more specific ... I got acquainted with one specific BPMS, which should simplify the implementation of a business process by setting rules. But for me as a developer it is difficult to work with the system. I would like to work with text files that I can reorganize, and I would like to be able to choose the right technology or structure for the work that I have to do. Instead, the system makes me tune.

There are rules in which I can use java, but even then I have to stick with the system editor without intellisense, etc.

So, this leads me to the answer to my own question - I would like to use the tools that I'm used to, instead of learning to work with BPMS (at least the one I know), because it limits me how it helps . The BPMS I know is the foundation it's hard to escape from! At this time, I would prefer a structure like Grail over any BPMS I know.

So maybe a more specific question: do you feel the same or are there BPMS that support you in the development company and think like a developer, or do most of them force you to do your job differently?

Answer 1

Not sure what you are asking for, but the choice of BPM versus simple programming will depend on requirements. "Business process" is a relatively vague term in software development.

Here are some criteria to evaluate your needs:

• complexity of the rules. Are the decisions / rules embodied in your process simple, complex, customizable, hard-coded?
• process volatility. How often does your process change? Who should be able to make changes?
• The need for integration - is your process implemented using multiple heterogeneous services or is everything implemented in one language?
• synchronous / asynchrounous - is your process “lengthy” with the need to handle asynchronous actions?
• human tasks. Is your process connected with human interaction, with the task / appointment of people in accordance with their roles / responsibilities?
• process monitoring. What is the level of control you want to use for existing process instances? Do you need to check actions, etc.?
• error processing. Depending on the preceding paragraphs, how do you plan to deal with errors or repeat the erroneous execution of the process?

Depending on the answer to these questions, you can understand that your process is closer to a simple state diagram with several actions and decisions that can be performed in sequence, or you can understand that you need something more thoughtful and that you don’t want re-do it all yourself.

Between simple programming and a full-featured BPM solution (for example, an Oracle BPM suite that contains BPEL , an engine rule , etc.), there are intermediate solutions like jBPM or the Windows Workflow Foundation, and possibly many others. These interim solutions are often a good compromise.

Answer 2

In my experience, the development environments provided by BPMS are third-rate, unproductive and practically make you write hard-to-maintain, poorly designed code (due to their limitations). Almost all the “functions” (user interface, integration, etc.) provided by the BPMS system that I am familiar with (the one that was sold by this company named in its database) were not worth the money we paid.

If you are forced to use BPMS as a developer, my advice would be to build as much of your application as possible in a normal development environment, such as Java or .NET, build as little as possible in the BPMS environment itself, and integrate the two. The only thing that needs to be done in BPMS is the minimum for the business process to work.

Answer 3

I have worked with Biztalk in the past and recently with JBPM. My opinion is biased towards BPM for the following reasons:

• A steep learning curve. To do the work on the process, I have to understand how the system and the editor work. It is quite difficult for a developer to understand the system, not to mention a business user. Drag and drop and visual presentation are great demo tools. This certainly impresses the managers (who ultimately pay for it), but the developer’s productivity just drops.

• Non-developers alter the workflow: I have not seen one BPM solution do this flawlessly. Although this does not look like code, right-click on the box and you need to put the code, otherwise it will not work. So you definitely need a developer. The best part is that it is not friendly to developers or business users, just a demo user interface.

• Testing and refactoring: it’s almost impossible to validate a BPMS drive. You have "unit test frameworks", but most of them are hacks and difficult to use. I recently tried JBPM; In the end, I wrote a lot of stigma code and fake workflow handlers to make it work. For me, a break in the deal is refactoring. If a business radically changes his mind about what a business process should look like, then luck will reinstall the boxes, because just reinstalling them will not work, all variables associated with the boxes should also be regrouped. I would prefer IDE credentials and tests to reorganize my business process.

If your application has a workflow, you can try the workflow library (with or without a permanent state). It will still manage your workflows without any bloat that comes with BPM. If a business user needs to understand the code, let the business prepare good flow diagrams of the processes and translate them into good domain-driven code. Use cucumber style acceptance tests to bring developers and businesses together. BPM is simply that trying to do too many things and ultimately doing it all badly.

Answer 4

BPMS is a lot of a common business case, a precedent has already been implemented. So you just need to know how to use it. For a normal workflow, you don’t even need to write a single line of code, although in most cases you will have to write some scripts to cover everything that has not yet been implemented.

Easy programming - just use the IDE to crack the code. Positive side: more control. Negative? Many times it takes to rewrite the template code. And you must support them.

So, in a nutshell, I would prefer a business process management system. I would recommend ProcessMaker . It has an intuitive process designer that allows you to design a workflow using drag and drop. And you can always write trigger to extend the functionality of the process. It is also an open source.