Lately I have been reading the hype surrounding the concept of Business Process Modeling (BPM) systems. I always take this stuff with a grain of salt because I have not seen an idea that lived up the hype since the Object Oriented hype of the early nineties. I know some would debate that point and of course I don’t mean to say that OO lived up to some of the more absurd hype. I remember some marketing fools actually were saying that OO would allow us to get rid of programmers. However, in this case, I think BPM and Graph Oriented Design/Programming has the potential to rival OO in its impact on our industry and jBPM is an excellent entry into this market.
The idea behind BPM is simple yet powerful: let the business analysts define the business process being automated and translate that directly into a configuration for a controller that will manage that process. In a real sense we have been doing this for a long time. The BA’s define what the system is supposed to do and the developers then create code that carries it out. How we dealt with wait states and parallel business processes were largely left to the development team to figure out. There have been tools to help us in this regards but none as extensive as is offered in the current BPM offerings.
Flow charts and state diagrams are easy for non technical people to get their heads around. It communicates something to them where Class Diagrams and Object Diagrams are just lost on most folks. UML’s activity diagrams are a little easier to understand then the collaboration diagrams. That is why people have used them so extensively.
jBPM builds on this fact by providing a GUI for creation of the process graphs. The graphs are created using an Eclipse plugin. You are also free to modify the XML configuration file which is straightforward and easy to understand. JBoss has a standalone version on their roadmap so hopefully we will see that soon since most business analysts don’t have Eclipse installed.
Once the BAs create the process diagram the developers can add actions to the various transition and state entry/exit events. These actions will actually carry out the defined business process. The process flow can be changed and the actions will be called according to the new flow. In many cases significant logic changes can be made just by rearranging the process model. Of course sometimes, an action might rely on some previous step that is now not being completed but this sort of dependency is something that we should avoid. The discipline of developing loosely coupled code is one that any programmer can benefit from but will become imperative in the world of the BPM developer.
I suggest checking out this entry into the BPM market and seeing what you think.