Process Management And Decision Management

by FICO

(Posted by guest blogger, James Taylor)

I posted a little piece on the potential unification of business processes and business rules on my other blog recently - Please don't just unify rules and process. This prompted some very interesting comments and links from a variety of sources and made me think it was worth recapping here.

The value of keeping business rules, specifically the business rules that drive business decision-making, separate from the specification of a business process that needs a decision made have been covered on this blog before:

Long running processes should get the right rules for a decision at the point in time that the decision is being made and not lock in those rules when the process is first instantiated.
Decisions, and the rules behind them, may need to be shared across many processes and systems not built with a process point of view.
The rate of change, and the ownership of that change, may be quite different for the definition of a process and the definition of the decisions within it.

In the end it comes down to the fact that process agility is not the same as decision agility. If agility is about sensing and then (correctly) responding to a business change I should be able to make various kinds of change depending on what is called for. If I need to change my process then I may well have to also change some rules in the decisions used by those processes and I may well find it easiest to discuss the changes needed to the process in terms of "process rules". The reverse, however, is not true. I might change the decision as to what offer to make, what price to use, what shipment date to promise without in any way changing the process of completing the order. This is decision agility and a unified process/rule view is not going to help.

One of the main causes of confusion comes from failing to differentiate between rules as a way to describe behavior (the business rules approach, you might say) and the specification of decisions using business rules. Business rules are declarative, atomic and business-friendly and so make a great tool when describing process flow or event correlation. CEP engines and BPM tools alike should support rules constructs for this reason. However, managing business decisions is a separate activity that also requires rules and typically requires far more rules, rules that change more often and rules that have more domain knowledge within them. These kinds of rules are better managed using a separate business rules management system (BRMS) so that they can be shared and reused across decisions, across processes and across systems.

There are some other things to note:

Decisions are typically stateless where event processing and business process execution are stateful. Rules for decisions therefore have different constructs from rules for business process or event processing
It has been said that rules and processes are tightly linked. Well yes and no. Yes, many processes benefit from being described at least partly in a rules-based way. No, this is not true of the rules that are used to implement the business decisions because business decisions should not be tightly coupled with the processes that use them.
A unified environment might make it easier to manage processes but there would still be a real need to manage decisions separately - this is the premise of enterprise decision management.
Data and rules are also tightly related yet no-one proposes doing away with separate rules and database management. There are rules for metadata and rules in MDM for example. Again, this is not the same as the rules you need for decisions.
Unified audit trails is something that might be useful but I don't think this benefits from a unified environment either as other things besides rules and process need to be in the audit trail.
Simulation of potential changes is the one area where a loose coupling makes life harder. I don't think this is enough of a problem to justify coupling but I do think it is an area that needs work.

There's much more that can be said on this but here are some links in which I think most of what could be said has been: