Since I commented on jBpm 2.0 model earlier in this blog, I have been asked to review jBpm 3.0 beta. This is not really a review per se, but my quick observations after spending a couple of hours on jBpm-3.0-beta4 and jBpm-bpel-1.0-alpha1.
jBpm 3.0 is essentially has the same underlying model as its predecessor, and that isn't surprising. From the architectural view point, it has more of a pluggable architecture (i.e., we can plug in our own modules that take up certain workflow responsibilities, for example, task handling), which can be a good thing. There is also a new graphical designer, which I didn't check out. There are a few implementation enhancements related to persistence and such, as well as many improvements related to deployment and documentation. However, I didn't see any notable changes or improvements from the modeling perspective.
The BPEL component, which is in alpha1 stage, is in very early stages of development. A full-blown implementation of the BPEL standard is not trivial, and I don't expect to see this component being ready atleast until the end of 2005. Some BPEL constructs have been added including messages and message correlations, but I don't know how complete they are. The current model still remains void of some non-trivial constructs such as scopes, compensations, and fault handlers. Some diligent analysis is required on my part before I can conclude whether or not jBpm can support all control flow constructs that BPEL specifies.
Overall, nothing in jBpm 3.0 made me change my earlier opinion that jBpm model is ad hoc and suboptimal, but Tom Baeyens has a different opinion (I hope that he is right and I am wrong). That said, I won't hesitate to use jBpm where ever I can, if I find it sufficient to fit the needs of the situation at hand.
In this well-written article, Michael Havey explains the two most popular theories that are in vogue among the BPM crowd, which are Pi-Calculus and Petri Nets. The latter served my needs so far in implementing BPM systems I needed. My expertise and understanding of Pi-Calculus is less deep, and I haven't built any systems based on it. There is plenty of rigorous research concerning aplication of Petri Net theory to BPM/Workflow, but on the contrary, there isn't much concerning Pi-C and BPM. It however rules on the hype scale, probably because it is new and less known.
There is a huge revival of interest in rule systems/engines - this time in the conext of managing 'business rules', not as an exercise in AI. The main premise of business rules management trend is that business rules should be extracted out of code and put under the control of business users. And that these users should be able to change the rules on-the-fly without needing to call upon a programmer. The software systems now are governed by these business rules, and their execution behavior may be altered with ease by the very people who best understand the business. That's neat. And very useful.
The scope of business rules is large, and the term 'business rule' could mean many things - facts/assertions (e.g., interest rate today is 5.75%), derivation rules (e.g., if total puchase > $300, discount rate is 10%), action rules (e.g., if payment is late by more than 45 days, call customer), constraints (e.g., a Gold customer never has credit score less than 650), and such. These rules can be organized in many forms including propositions, if-then-else clauses, decision tables, and decision trees. It is possible, in theory, to consolidate all these rules in a sophisticated rules reasoning system, and let everything in IT be driven by that.
BPM is obviously concerned with rules because business processes are governed by business rules. Many BPM systems today support business rules management of some sort, either by directly suporting it or by integrating with third party rules systems such as ILog Rules, Jess, and Corticon.
Compared to all the buzz, I think the real progress has been somewhat limited so far. It is possible that the trend is still in the early stages and will catch on rapidly in the coming years. It is also possible that this trend will fail to deliver the same way the expert systems have failed.
I haven't looked at this specific model myself, so I can't judge how good or complete it is. I do think a maturity model for BPM makes sense and could provide a valuable tool for understanding where the BPM gaps are within an organization.
An excerpt from the CIO Magazine Article: "Many companies asked us how much business process management they should do and how well they conduct business process management right now," Rosemann says. "Our model lets them measure business process management along five factors. Those five factors are information technology, methodology, performance management, culture and accountability."
Given the generic definition of 'business process', the overall workflow/BPM market ought to be huge, at least a few 10's of billions of dollars huge. But, it remains a very fragmented market with no one controlling a significant piece of the pie. One Aberdeen Group report in 2003 stated that IBM dominates the BPM market with about 16 percent market share, but I'd venture to guess it actually has less share than that, depending on how we define BPM. There are no pure-play workflow/BPM vendors that are big. IBMs, BEAs and Oralces don't count as pure-plays since they offer comprehensive solutions to coporate IT departments, not stand-alone workflow products. Most workflow vendors address their own specific vertical markets with tons of add-ons. Most pure-play workflow startups end up changing their business models to offer industry-specific solutions, or going out of business. Given the current state, will the BPM market be consolidated? What will lead to such consolidation? Will there be a couple of BPM players controllong 95% of the market? I tend to think it is not going to happen in the foreseeable future. The reasons are many, but the primary reason lies in the fact that 'BPM' is not all about technology. No vendor today can sell a BPM product to a customer and walk away expecting the customer to implement a meaningful solution to his/her business problem. Given a BPM system, most customer do not know how to convert a business problem to a technical BPM solution. Vendors end up needing to know too much about the domain in order to help their customers implement meaningful solutions, often requiring them to add domain-specific extensions. No vendor can afford to know enough about all the domains or even half of them.
It is conceivable that, at some point in the future, there may be one or two major vendors offering the 'core' BPM technology, with many middle tier vendors offering domain specific extensions/solutions. The emerging standards such as BPEL may help such consolidation, when the market truly accepts them as standards. Some version of BPEL in the future, may be BPEL 4.0, may become such a standard, but there is a long way between BPEL 1.1 and BPEL 4.0. Or may be it is an impossible way.
It will be interesting to watch how the BPM market evolves with all the major players (Microsoft, IBM, Oracle, BEA and others) vying for a big share of the market.
