Mark Proctor and Kris Verlaenen have posted an interesting description of JBoss’s vision for unifying rules and processes. I have to say that on this debate I think I broadly side with James Taylor, who has also posted a response.

In my opinion this debate involves runtime and design-time considerations.

Runtime

At runtime we are presented with two execution models: a graph execution model for processes, and the pattern-matching model for rules. BPM tools traditionally excel (or struggle, depending on your experience!) to offer state management, allowing long-running processes to be safely persisted and “rehydrated” based on some system event. Most rule-based products offer relatively little in the way of long-lived state and transaction management, concentrating instead on the automation of “point in time” decisions. It is relatively easy to expose a set-of-rules (in the loosest sense) as a procedural function (web service, Java method, asynchronous message driven bean etc.) and invoke the “function” from a higher-level orchestration (Java program or BPM process for example). Loose coupling may, or may not, be preserved, depending on how much model sharing the architect would like between the orchestration and the decision service.

If you move beyond functional invocation then you must rely on a shared data context between the orchestration and the rules, such as the rule-engine working memory for example. The coupling naturally becomes tight as your orchestration no longer has a clear interface for decisions but rather throws events into a shared context and side-effects happen. This pattern can be very powerful for certain scenarios, however it is much more sophisticated than the usually idempotent stateless invocation of a decision service. Transactions, clustering, high-availability and replication, scalability and memory usage tend to rear their ugly heads sooner rather than later!

Design Time

On the design-time side of the debate I’d say that things are more complex and nuanced. The primary user of a BPM tool is a human being. A complex business process is being moved through a life-cycle, however that life-cycle typically involves human tasks for approval, review, task assignment or implementation. Business processes therefore tend to evolve rather slowly (months), because human beings have a finite ability to adapt to changing processes. This is in contrast to an automated decision service implemented using rules (eligibility or credit scoring for example). Changes to the scoring algorithm could happen hourly, without causing organizational problems. However, changes to the order fulfillment process are likely to be much more gradual, as it is impossible to retrain staff and suppliers, maintaining job-satisfaction and quality, in the face of business processes undergoing constant change.

So, although there may be value to maintaining referential links between processes and groups of rules (for reporting or drill-down for example), the two entities do not typically serve the same ends, or share the same change-cycle. Therefore the standard pattern is for the coupling between the two to be quite loose, with a formal functional interface defined for automated decisions. This allows the rules to evolve independent of the orchestration, with zero impact as long as the functional interface does not change. It is also very nice to be able to test an automated decision outside of the context of its orchestration, as a standalone (functional) entity.

The Engineer’s View

This is not to deny that there are technologies and challenges that BPM and rules share in common (expression language, IDE concepts, management and monitoring requirements etc), and I suspect that this is primarily what Mark was alluding to in his post - particularly when he says the JBoss BPM and rules teams may merge. However in my opinion this is primarily for the convenience of the product vendor, rather than a direct benefit to the customer. I think the post from Tom Baeyens bears this out. For example, while I was working at BEA Systems we used the core Rule Engine expression language to define Portal security and access control policies, although I suspect few customers knew this.

Process Virtual Machine

As a side-note, I have to admit I have a rather soft spot for Tom Baeyens’ Process Virtual Machine concept. It reminds me of the Virtual Rule Engine Specification I proposed 3 years ago. Clearly the BPM space is faced with some of the same challenges as the rules space in terms of language standardization. However, the goals of the VRES and PVM concepts both appear to be to standardize execution semantics in the face of a fragmented marketplace.

Conclusions

Perhaps one day we will have the unified “business management system” that combines data, rules and processes, with business people defining and managing processes, services, rules and seamlessly moving between them. However based on the current adoption of RDBMS, BPM, BRMS, BI and the rather basic change management and modeling practices in many organizations I fear that day is still rather a long way off. One thing we also hear loud and clear from our business users is that they don’t want to become “traditional” programmers. Within the ILOG BRMS products we strive to “do one thing well” — provide a BRMS that is both powerful and flexible enough to integrate into a wide variety of design and runtime contexts, using out of the box functionality augmented by a rich set of APIs.

Posted by Daniel Selman in BRMS Architecture. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.