Ten Business Rules Usage Patterns in BPM and Business Events

In my opinion, Progress Software's acquisition of Corticon marks the beginning of the end of the monolithic ‘rules-engine’. The idea that there is a business rules engine that is ‘called’ by a ‘program’ is past and there is a more nuanced understanding of the role of business. By my estimate there are at least 10 separate usages of business rules within business processes and business events.

Firstly, business rules play an important role in the rules-driven process pattern. The common monolithic conception of business rules is that it is only an element of a decision that affects the gateways of one process.
There are various opinions about this and certainly I have mine. Yet, it as the BPM industry matures it is probably wise to use more standard research methods to develop an approach. Researchers at Georgia State University and Utrecht University have identified five categories of business rules that have a behavioral influence on the business process in terms of mitigating operational risk or achieving compliance to regulation.
The five usage categories are:

1. Rules for task sequencing
2. Rules for actor inclusion or task assignment
3. Rules for effect sequencing or gateway conditions
4. Rules for data / information registration
5. Rules for detection control or event reponses

Briefly, these five usage categories are described:

Task Sequencing: these rules influence the position of one or multiple activities/events/decision (hence process elements) within a business process.  Most often, to create a process that is compliant with the business rules, process elements are simply added, re-ordered or removed. That is, the existing process model is updated to reflect the new rules.

Actor Inclusion/Interaction or Task Assignment: These are rules that influence the assignment of tasks or decision to specific actors. There are several approaches to creating a complaint process. Firstly, defined actors, in the form of participants, can be removed/added or appointed to different elements inside the process. In addition, a processes can call business rules to delegate the activity to the correct actor.

Effect Sequencing or Gateway Conditions: These rules influence the paths chosen by gateways or conditional sequences inside the process. This is the classic pattern of the values, created by the rules, setting the conditions at gateways and directing the flow of the process. That is: the path chosen is directed by an evaluation of business rules associated with individual transaction. This is more dynamic than task sequencing where rules influence the arrangement of the paths.  An example of effect sequencing is a shipping process where, depending on the needs of the shipment, different transportation process activities need to be executed. This is the most common perception of processes and rules. To make the process compliant, business rules need to be enforced during runtime.

Data / Information Registration or Event Responses: These rules influence the recording and viewing of data and information, and the authorization to access it. Most often, to create a process that is compliant with the business rules, internal controls govern timing: how long must the recorded data be kept accurate and the predefined format of complete or registered data. That is: the registered data must contain the following information and authorization, restricting access to predefined user and roles.

Detection Control or Event Reponses: These rules influence how a process responds to events. Events can be external or internal. External events might include weather, or financial events. Internal events arise from the direct or audited results of an activity or processes.  Most often, to create a process that is compliant with the business rules multiple solutions can be used: process elements can be added, reordered or removed, we can have the process respond to an ‘event channel’ or, a new business process can be created to perform the event control.

The last type can be expanded further. Business Events open another set of 5 patterns for business rules. In the Microguide we defined several classes of decision for event processing. These usually occur in the following order: 

1. Detection, 
2. Distribution, 
3. Aggregation 
4. Correlation 
5. Assignment

Not every event processor includes all of these steps. Also, after detection, it is not required for these steps to be executed in this order. The list shown is ideal, in theory, for all event processing situations.

Detection: In event detection, logic is applied to data monitored by the event detector. A business-relevant or ‘event-of interest’ is discovered when the event process matches the logic with the data.

Distribution: In event distribution, the detected event is immediately alerted to the affected process or systems, according the logic and levels of participation. Rules logic decides the level of involvement and the destination of the distributed event. Distribution logic can simplistic, as in a burglar alarm during irregular hours. Complex distribution logic might deliver the event based on the scale of the data within the event.
Events are distributed through two distinct patterns; either through a message, or a broadcast. The message corresponds to the BPMN message. Event processing targets the event activated messages at a process instance. The broadcast distribution method is denoted as a signal event in BPMN, and is analogous to a radio signal.  While a message persists after it is sent, a broadcast is only relevant for a short period of time.

Aggregation: Many business events are only meaningful in combination with other events of a similar or related nature. Logical significance might arise from the timing or temporal nature of the other events. In aggregation, event processing uses business rules logic to identify significant events from a group of events.
Correlation: Event processing includes a correlation step. Event processing can play a role, by detecting internal or external events and correlating these with concurrent processes or data in the enterprise. Active business processes might be identified as intended recipients. Business rules define what data or process states are included in the correlations and the logic of the match.

Assignment: At the conclusion of the cycle, in assignment, the event is assigned to one or more processes. Business rules can choose which process is assigned the event for action. As with all rules, the assignment can be as straightforward as the unconditional assignment to a single process or it can be a time, capability and dependent assignment.

An example of this is shown in the figure below:

Process modelers and business decision modelers use the three metaphors of business processes, business rule and business events these to model solutions. In early incarnation of the business rules engine, the BRMS was built as a separate engine to be included in a batch or separate process. Our understanding of the use of business rules has become more nuanced and more focused on the intended usages. If you model your processes with these rules your rules will be more focused and more compact.

Tom Debevoise

Process, Rules & Events: Critical Business Modeling Methods

Business process modeling, decisions, and business events describe the business, not the technical details. These are evolving, strategic management methods that meet today’s challenges. They work together to make it simple for an organization to update underlying rules or processes activities without complicated redeployments of production systems.

 

Figure for business rule pattern 3, the sequence or path of the process is controlled by the decision graph.

Over the last 5 years, BPM/BR represented a change in the language and symbols that we use to describe business models systems—these methods have become more business-centered and less tied to the technical details of systems. In the past, the IT industry has moved first from information engineering (IE), to object-oriented software engineering (OOSE), to use case analysis. Along the way, commercial off-the-shelf ERP software such as SAP and Oracle Financials became an important part of commonly used technology. The latest methods changed the focus from mathematical theories of data and functions into graphical notations of what the business does. For instance, IE uses an entity relationship diagram (ERD). The ERD depicts relational calculus formulas. A business process diagram, in BPMN, looks and acts like a white board, and business rules have similar graphical descriptions such as decision graphs and decision tables for the rules.

With older methods, data modeling and use case analysis created an immediately outdated technical snapshot of how the organization does business. Businesses always need to change their events, processes and rules to remain competitive. Data modeling and use case analysis do not easily help with these changes in applications. So, in some ways, software based on the metaphors of Process, Event and Decisions is the next step in modern software. Instead of writing programs in Java or C#, these organizations model what the business does in words and diagrams. To update the process or rule, you update the diagrams.

With the acquisition of Inubit, Bosch Software Innovations will soon be offering combined products for Business Process Management (BPM), Business Rules Management (BRM), Business Data Management, and Infrastructure Management. These products form the basis for applications in the Internet of Things and Services as well as for the development of business models based on those applications.

Second Edition Microguide Process Modeling in BPMN Released

I would like to announce the availability of second edition of the ‘Microguide to BPMN 2.0’. Of the many books available on BPMN, this is to first to enter its second edition in a new and enhanced form.  

Amazon Page

A new era for process modeling has arisen and in our second edition, we continue with the most concise coverage of BPMN available. We cover more ‘real-life’ business scenarios and model more unstructured, monitored and indefinite activities in BPM. The text not only corporates new metaphors of events and decision-directed event processing, it also covers 15 different BPM design patterns, forged in the furnace of practical, state-of-the-art process modeling, that provide a shortcut to a proven design. The material in this comprehensive, focused book has been gleaned from actual practices and proven in many of the most advanced processes in production today.

In concise language, we explain how to build visible, agile and powerful process that meet the needs of a chaotic and globally federated environment. It truly is an essential resource on the practical application of event, decision and process modeling.

This is my forth book project, and a few years ago I wrote some words of wisdom on the topic of book writing. If you are thinking about writing a book you might read them here.

Over the next months I intend to focus on BPM and BPMN on this Blog.

The book is available from amazon at http://tinyurl.com/MicroguideBPMN.

- Tom Debevoise

BPMN in Visio 2010

I have been looking at Microsoft Visio 2010 and I would recommend it to anyone seeking a simple process modeling requirements tool. Ultimately, when your 'requirements' phase in process modeling is complete, the business analysts must move away from Visio and into the business process management suite.

There are many, many users of Visio who are 'process focused'. Moreover, there has been a significant investment in process modeling using Visio. When teams, who have not used an execution-oriented framework such as PMF, move these models into execution there will be issues. Visio 2010 Premium will help a bit by doing a very competent job at supporting early (learning and requirements) efforts in process modeling. The 'check diagram' function checks the proper syntax of the BPMN shapes. For instance in the diagram below, there are two errors: a message is flowing the wrong way and there is a 'hanging' activity.

Wrong

After you correct the issues the errors disappear.



Casewise, Orbis and others provide Visio 'bridges'.  Yet, all these will change when other vendors will seek to capitalize on Visio 2010's new BPMN features. This tool also supports moving process onto SharePoint 2010. Overall, I commend the Microsoft Visio BPMN team for their efforts.

Business Rules and Business Process Modeling Simplified

In BPMN 2.0 there is a shape for business rules:



 This shape denotes the place within the process model which calls business rules and obtains decision output.  The question is, how do you use it?

The difference between process and rules is simple; processes are stateful and rules are stateless. In BPMN a process has an explicit or implicit single start and one or more stops. In business rules there is no start or stop. It is an expression of a sequence of logical conditions.

Consider the figure below:



Simple Process with exclusive gateway, the process corresponds to the process: Start: When A Condition: Start Activity A When B Condition: start activity B, When either complete: Stop

This simple process uses the exclusive gateway to choose which activity to run. The activity, A or B, will run for an indeterminate time. When it is done the end is reached. A simple flow rule from Visual Rules is shown in Figure 2.  A flow rule is a graphical representation of a path of logic. There is no time element to the evaluation; either condition A or Condition B will be the outcome of the evaluation of the conditions in the two gateways-there is no time element to consider.





Figure 2: Simple decision graph with two exclusive outcomes, the diagram corresponds to the logic IF A condition Then A Outcome else If B Condition then B Outcome.

The two figures compare and contrast the similarities of BPMN and business rules. Both evaluate the logic conditions to decide which process activity or outcome to choose. The contrast is in the time element. This is what we mean when we stay the process is stateful and the decision graph is stateless.

If we connect the flow rule with the process then the process model looks like this:



This is simple, but most process decision are more complicated than that. I discuss process decisions in a white paper located here: