Bruce Silver wrote a couple of interesting posts on this topic – Integrating Process and Rules – Part 1 and Part 2. Reading Bruce’s posts, and thinking back on the various posts I have written about business process and business decision management (Risks of pursuing BPM without decisioning, Adding decisioning to your BPM initiative or this webinar recording), it seems to me that there is an emerging consensus on how to bring these things together. This is important as Bruce points out:
in decision-intensive processes like lending or claims, process and decision modeling are separate large-scale activities performed concurrently, usually by independent teams.
Bruce goes on to say that
Integrating BPMN and decision modeling ultimately comes down to properly representing decisions and their constituent rule families in the context of BPMN subprocesses and tasks.
To understand this you need to know a little about The Decision Model – an approach for analyzing and modeling the business rules in your decisions (check out my blog post here and this webinar by Barb von Halle for more detail). Each Decision Model describes the rules that derive a single, business conclusion in a purely declarative way – there is no procedural logic in one. Rules and rule families make up a Decision Model and there is a notation and modeling approach to ensure these are complete and accurate. If you want to think about this in terms of a Business Rules Management System, each Decision Model specifies the logic requirement for a single Rule Set (see this post for more on rules, rule sets and decisions).
While some, perhaps many, operational business decisions require only a single rule set to execute and a single Decision Model to describe them, many are more complex. Because each decision model is a single declarative “space” and maps to a ruleset, you need to be able to group multiple Decision Models into an operational business decision definition. Such a business decision definition is going to be a collection of steps, most of which will correspond to a ruleset (implementation) or Decision Model (specification). The overall decision should be stateless and should have no side effects (allowing it be implemented as a Decision Service that can be both part of a process and available to other processes and systems.
A number of business rules pureplays support something called a Rule Flow (I prefer Decision Flow) to do this – FICO, IBM/ILOG, Corticon and InRule, for instance, all have such an artifact. This defines a series of steps and simple branches where each step could be a call to a function but is most likely to be the invocation of a rule set. A number of the newer players are heading down the same path, with SAP already offering a flow in its SAP Netweaver BRM product and Savvion discussing it. What is interesting is that the representation and capabilities of these flows is converging on a common set of elements:
- Using a subset of BPMN notation to describe them
- Mapping tasks to a single rule set or decision table
- Supporting most of the common branching artifacts
- Allowing for simple looping e.g. to invoke rules for each order item on an order
- Allowing for calls to sub flows
- Accessing additional data besides that being passed in from the calling process
- NOT handling most of the time out and exception handling that should be done by the calling process
While I like Decision Flow as a name for this I am beginning to think that Decision Process is a better one – essentially acknowledging that it is a kind of process. Unlike Bruce, I don’t think it is useful for the internal structure of a Decision Model or of an executable ruleset to be shown in the process diagram. Instead I would like to see these declarative objects to be represented as Tasks with the Decision Process flow collecting them into a single, stateless, side-effect free sub-process that can be called and used whenever necessary. Such a Decision Process could be deployed as a stateless, side-effect less Decision Service for use beyond processes as well as re-used across multiple processes. Rules, rule families, rule sets and decision models could all be reused across Decision Processes too, allowing for granular re-use and other rule analysis techniques (such as those described by Ron Ross or by the various BRMS vendors) could also be used.
What do you all think?