Steve Zisk of Pegasystems discussed decision management with a perspective on the combination of BPMS and BRMS (as you might expect from someone from Pega, whose product is a BPMS built on a BRMS): considering where change occurs and has to be managed, how rules and process interact, and what types of rules belong in which system.
In many cases, rules are integrated with process through loose integration: a process makes a call to a rules engine and passes over the information required to make a decision, and the rules engine sends back the decision or any resulting error conditions. This loose coupling makes for good separation of rules and process, and treats the rules engine as a black box from the point of view of the process, but doesn’t allow you to see how rules may interact. It also makes it difficult when the parameters that drive rules change: there may be a new parameter that has to be collected at the UI level, held within process instance parameters and passed through to the rules engine, not just a change to the rules. Pega believes that you have to have rules infused into the process in order to make process and rules work together, and to be completely agile.
Looking at an event-driven architecture, you can consider three classes of events: business, external and systems. We’re concerned primarily with business events here, since those are the ones that have to be displayed to a user, used to derive recommendations to display to a user, or used by users in order to make business decisions. Systems that need to involved human decisions with many complex events need to have a tighter integration between events, processes and rules.
Case management is about more than just collections of information: a case is the coordination of multiple units of work towards a concrete objective to meet a business need of an external customer, an internal customer, a partner or another agency. Cases respond to and generate events, both human events (such as phone calls) and automated events (such as followup reminders or fraud detection alerts).
Steve covered a number of case studies and use cases discussing the interaction between rules, processes and events, highlighting the need for close integration between these, as well as the need for rules versioning.