Certainly, combining business process modeling with a business rules approach can create comprehensive, agile solutions that support a business model. Yet, it is not always easy to understand the role of these visual modeling approaches.
Technically, the BPM/Business Rules approach places process logic with the BPM suite and decision logic in the business rules management system (BRMS). The process logic in a BPM suite sequences and controls activities and launches and cancels processes. Control is achieved with timers and exception handlers. Processes can be designed to recover from errors, restart processes and coordinate activities. The BRMS effectively designs, organizes and executes the logic behind a process decision. An effective BRMS can handle any depth and complexity of decision logic, including computationally complex logic and dense logic.
Clearly, Business Process Modeling Notation (BPMN) and BRMS are important functions for managing a business process. Moreover, processes and decisions can be reused interchangeably.
Assigning the correct problem domain or requirements to Process or Business Decision Logic is not always clear.
Business Process Modeling Notation is the global standard for describing business processes, yet there are no visual standards for business rules. That said, perhaps we can compare Innovations’ Visual Rules notation with analogous shapes in BPMN and discover some of the differences and similarities between modeling business processes and modeling decision logic.
Decisions and Gateways
Probably, the foundation element in Visual Rules is the Decision Shape:
It is used whenever a rule needs to make a distinction between two or more different situations. In general the Decision shape runs down a sequence of choices. You can also configure the Decision to evaluate multiple conditions. The equivalent shapes in BPMN are the exclusive and inclusive data-based gateways:
The outcome of the two gateways is the same as the Visual Rules decision shape: decide among conditions in the flow of the process or rule flow. In Visual Rules, the branch of a decision can end abruptly with and assignment or ‘action’. It has been graphically designed to be concise. A Visual Rules decision set in a rule flow can span many dozens (or even hundreds) of decisions. The equivalent BPMN diagram would be unwieldy.
The objective of Visual Rules is to model business rules that decide with data, while a process mainly coordinates the activities of participants (departments, users and systems). So Visual Rules has no equivalent for the parallel or complex gateway in BPMN. Part of that process coordination might require the same logic as a decision with data. For instance, process attributes might direct a transaction to accounts payable or elevate an approval based of the size of the transaction. Hence, the overlap. Processes manage the concurrency of activities. The parallel gateway can ‘launch’ activities in parallel (split) and wait or merge the activities when they are done. I have never encountered the need to evaluate business rules decisions in parallel.
Subprocesses and Rule Calls
Now let’s reverse the comparison. In BPMN an important shape is the subprocess:
In Visual Rules the nearest equivalents are the call of a flow rule and the call of a decision table:
In BPMN, a subprocess can be self-contained within a participant lane or it can be a reference. In Visual Rules the call to other Flow Rules and Decision Tables enable reuse of logic in decision-supported business rules. You can organize your logic with the call to decision tables and other flow rules. Sets of decisions can be federated, organized according to a topic or business area, or divided into areas of expertise.
The BPMN subprocess might seem similar, yet it is mostly a way to organize and control activities within a process, and reduce the amount of needed notation. For instance, a process might need to post transactions to three operational systems. Grouping these into a subprocess permits the transaction to be treated and compensated as a single process. The subprocess can be timed-out with a timer event attached to the boundary.
Loops and Loops
Speaking of subprocesses, Visual Rules also supports loops with the shape:
There are three kinds of loops supported in Visual Rules: Looping while a condition exists; for a number of times with a counter; and for records in a list. There are (sort-of) equivalents in BPMN:
Standard Loop:
and Multi Instance:
Again, as with other BPMN shapes, the similarities between the Visual Rules loops and BPMN loops are overlapping yet divergent. Visual Rules loops traverse arrays and vectors of records and apply business rules. These loopsare important for developing complex algorithms. BPMN subprocess loops organize process logic. Also, the BPMN multi instance loop can start multiple process threads.
Exceptions and Others
Visual Rules can raise and handle exceptions such as database errors, math errors, general business exceptions and others. The Visual Rules shapes for these are (raise and handle):
In BPMN the exceptions, known as errors, are shown as:
Without delving into the details of BPMN, there are throwing and catching error events. Generally, BPMN exceptions are connected to the boundaries of subprocess.
There are other parallels we can draw. I hope you can see these shapes have overlapping , yet divergent, purposes. In fact, with enough, albeit brute-force effort, there is very little logic that cannot be implemented in either BPMN or Visual Rules. The question is: what is the correct tool for the correct problem area?
BPMN versus Visual Rules: Teams Address the Problem with the Proper Tool
I believe these are the salient features of the different problem domains.
A Business decision is mostly stateless and time-invariant. Visual Rules is adept at documenting and implementing complex decisions with clear, visual documentation. Moreover, business analysts can easily learn how to create and manage these decisions in Visual Rules. Next, Visual Rules is designed to complex logical decision: having thousands of branches, loops and decision tables. The Visual Rules Modeler is designed to permit detailed use-case testing, with data. You can debug and ’step’ through complex decisions.
Process logic is mostly concerned with coordinating and managing time-varying objectives and concomitant exceptions and states. BPM/BPMN is adept at managing process instances. Many BPMN shapes, such as the Timer, Error and Compensation Events have been designed to handle unforeseen process errors. BPMN is designed to model and document an enterprises business process. Most BPM tools can ‘play-back’ a process model for process verification. BPMN documents interactions among participants.
It is difficult to manage computationally complex and logically dense logic with BPMN. BPMN lacks the compact, organizational capabilities of a BRMS. Similarly, the BRMS lacks the process automation abilities in a BPMN engine. Because the objectives are different, it is expedient to separate process logic from and business decision logic.
Technology is Important, Peoples and Organizations are More important
Recently, I asked Sandy Kimsley of Column 2 to provide a reference for a great quote she made about BPM/Business Rules. I thought it went something like this: “The Business Rules folks want the BPM tool to call the rules engine then go away and the BPM folks want to never call the rules engine” or something like that. When I asked her about this she said “I recall saying that the BPM people would build a huge decision tree in BPM rather than call BR, and the BR people just want the BPMS to have one step, which calls the BRMS.”
More to the point, the groups that manage processes and decision logics are very often different. A business process can cross different systems, department and organizations. Decisions are usually the responsibility of one organization (even if many provide the data).
In the business rules world, we often say that it is easier to change decision logic than it is to change process logic. This is conjecturing rather that stating facts. Today’s BPMS is as adept at managing change as the BRMS. Another favorite saying of the Business Rules community is that business rules change faster that the process. Again this is more conjecture. Both these opinions miss the central point. The team responsible for business rules is almost always different than the team managing the business process. The objective of today’s BPMS and BRMS is to end loose, verbal or documented requirements gathering and cede control to the owners of the requirements. One group of Subject Matter Experts (SME) uses BPMN to create processes. Another creates and manages the business rules. BPMN is a visual tool set that empowers process managers and subject experts. The Visual Rules’ BRMS is a visual tool set that empowers decision modelers and experts.
