I’m not a drooling rabid fan of JBoss’ jBPM workflow engine, but I do agree with many of the sentiments expressed by jBPM lead developer Tom Baeyens in “The State of Workflow,” on jboss.com.
If database systems are like a respected, wise man telling a clear story, then workflow must be a bunch of spoiled brats shouting their own truth at each other. …
[W]orkflow management systems are at the very initial phase of the technology hype curve. … One of the observations that form the basis of this statement is the overwhelming number of concepts used. None of the numerous specs and tools in this area is similar.
Baeyens explains in detail why the concept of “activities” should be discarded in favor of “states” and “actions.” Baeyens then:
Many vendors of workflow management systems will let you believe that with their graphical process designer it only takes a business analyst to create process definitions. This vision originates from the fact that programming is hard. …
I’d disagree with the assertion that “programming is hard.” Certainly it’s not easy, but it’s not as hard as developing and codifying the actual business procedures … finding that delicate balance between oversimplification and analyzing everything to death.
While not having to write code is a good thing, most vendors go overboard on this and don’t foresee a mechanism to integrate code into a process definition … Developing process definitions requires input from -and collaboration between- a business analyst and software developer. A good graphical process designer should support this collaboration.
Here I’d have to agree 2000 percent. A GUI workflow builder seems simple and “intuitive” at first glance. Just keep in mind that the actual workflow engine has no such sense of human intuition. It helps to be able to explain the fine details of complex processes in a language that the workflow engine speaks.
Recent Comments