In this article we show how business rule modeling plays an important role in achieving business process flexibility -- not just by separating the decision logic from the business process, but also by using business rules as the starting point to generate less complex and more flexible business process models by reducing them to their essence.

Flexibility and Compliance

Information Systems must flexibly support business processes that at the same time are compliant to the (intra-organizational) business policies and procedures and to the inter-organizational regulations and protocols the business has to observe.  Unfortunately, systems often make business processes more rigid than flexible by hard-coding rules and processes.  This compromises the business' ability to rapidly incorporate business policy change and regulatory change in the business processes.  Whenever the rules change, processes may have to change accordingly.

The key to business rules is that they make the knowledge about implicitly present policies and regulations explicitly traceable.  In this way, changes in policies and regulations can be traced back to the business processes where they are to be enforced, thereby enhancing flexibility and compliance.

When modeling business processes, we implicitly have the policies and regulations in mind, but usually little attention is paid to avoiding the hard-coding of these underlying rules directly into process models.  The issue here is the role of business rule modeling in achieving business process flexibility.  In particular, it is argued that flexible business process models require business rules as a declarative formalism to capture the semantics of policy and regulation. 

Separating Process and Decision Logic

It is well known that hard-coding the decision logic of calculations, inferences, and decision points into process models is not flexible.  As indicated in Figure 1, separating the rules that define the applicant type (the know) from the process (the flow) creates more flexible processes.

Figure 1.  Isolating applicant type rules.

Figure 2 is even more flexible.  The process is now reduced to its essence and not subject to major or minor changes in policies, applicant types, calculations, etc.

Figure 2.  Offloading the process.

Defining the Process

But what about the rules based on the following order policy?

Order policy:  "We can only ship the goods after we have received an official corresponding order."

Which process in Figure 3 is compliant with the rules?  What if the rules change?  Indeed, the process will have to change.

Figure 3.  Order handling processes.

Business rules define the semantics and constraints of business concepts, the reaction to business events, the constraints and preconditions on activities, the rights and obligations of actors, etc.  Therefore, business rules guide and constrain business processes, not only the calculations and validations but also the sequence and timing of activities.

How Business Rules Define and Simplify Processes

The Semantics of Business Vocabulary and Business Rules specification (SBVR), approved as an interim specification of the OMG, divides business rules into structural rules which express necessities and supplement definitions, and operative rules which express obligations and business conduct.

Let us have a look at some rule types, using the following example.  Figure 4 depicts an order-to-cash process model (in BPMN) from the point of view of the seller.  Where are the hidden and hard-coded business rules and how can we use the business rules to simplify the process model?

Figure 4.  An order-to-cash process model that can be simplified.

Different categories of business rules can be present in order to declaratively specify the control-flow (sequence and timing of activities), data (data validation and requirements) and resource perspectives (task allocation and data access rights) on business processes.

Some examples:

1. Integrity constraints are assertions over business concepts that must or should remain true and thus constrain the domain over which business facts can range.  In business process models, integrity constraints can lead to preconditions for specific activity types in the process model.  Moreover integrity constraints can lead to data validation rules for the case data that is exchanged in business processes.
   
   Checking these constraints should not be modeled as a step in the process model.  For instance, in the left-hand side of Figure 5, the data validation rule to enforce that "customers aged under 18 cannot place an order" is hard-coded in the diagram.
   
   However, integrity constraints should remain autonomous business rules.  During business process enactment, the system should autonomously decide when and how integrity constraints should be enforced.  This approach simplifies the modeling of business processes, as is depicted in the right-hand side of Figure 5.

Figure 5.  Enforcing the integrity constraint is not part of the process.

2. Derivations, inferences, calculations are statements that define new business concepts in terms of existing concepts.  In this way new facts can be derived from existing facts.  We often implicitly think of derivation rules and model them as decision logic in BPMN models.  For example, the left-hand side of Figure 6 depicts the logic that "loyal customers receive 10% discount."
   
   However, the decision logic should not appear in process models since rules change more often than processes.  It is up to the system to autonomously decide when the rule should be applied.
   
   This approach simplifies the modeling of business processes, as is depicted in the right-hand side of Figure 6.  Many BPM systems already provide this kind of flexibility.  Yet to our knowledge, the scope is often limited and implementations show a strong coupling between process and rule environment in which the process (execution) model makes explicit calls to a rule service.

Figure 6.  Separating the logic from the process.

3. Permissions and obligations of actors in a business interaction impose sequence and timing rules on business processes.  Assume an order-to-cash business process that can occur according to two distinct policies:  payment-after-shipment or shipment-after-payment.
   
   It can be formally shown that these permissions and obligations impose partial order constraints on the activities in a business processes.  Consider for instance the following rule about payment and shipment in the order-to-cash business process:

   shipment-after-payment:  "Goods can only be shipped after the corresponding order has been paid."

Of the six sequential order relations (Figure 7), only three are acceptable according to the rule.  Changing the rule would lead to a different process model.

Figure 7.  The shipment rule constrains the business process.

4. Reaction rules state which actions are to be undertaken, given the occurrence of a certain business event and the state of the process instance.  The reaction to a payment timeout (for example) can be formulated as follows "when the customer does not pay within 30 days, a payment violation notice is to be sent to the credit insurer."

An Architecture of Rules, Processes, and Services

The sequence, timing, and reaction rules on the activities in business processes are an important aspect of business process compliance.  Obtaining flexibility in the execution of rules and processes requires a service-oriented architecture (SOA) where services are related to rules and processes, and where both rules and processes are supported.

Figure 8 illustrates how the rules and process layer is situated above the service layer in this architecture.

Figure 8.  Business rules and processes in a Service-Oriented Architecture.

Conclusion

Information systems must flexibly support business processes that at the same time are compliant to the intra-organizational policies of the business and the inter-organizational regulations the business has to observe.  To achieve business process flexibility, we need a declarative approach in the modeling of business processes.  Business rules should not be hard-coded into control-flow-based process models.

References

[1] Debevoise, T., Business Process Management With a Business Rules Approach:  Implementing the Service Oriented Architecture, Business Knowledge Architects (2005).  

[2] Goedertier, S., Vanthienen, J., "Rule-based business process modeling and execution" in: Proceedings of the IEEE EDOC Workshop on Vocabularies Ontologies and Rules for The Enterprise (VORTE 2005).  CTIT Workshop Proceeding Series (ISSN 0929-0672), Enschede (2005).  

[3] Goedertier, S., Vanthienen, J., "Designing compliant business processes with obligations and permissions" in: Lecture Notes in Computer Science, Vol.  4103, Business Process Management Workshops, pp.  5 - 14 (2006).  

[4] Ross, R.G., Business Rule Concepts -- Getting to the Point of Knowledge, Business Rules Solutions, LLC; 2nd edition (2005).  

[5] Ross, R.G., "Rules and Processes:  Examples Showing How They Relate," Business Rules Journal, Vol.  7, No. 10 (Oct.  2006), URL:  http://www.BRCommunity.com/a2006/b315.html  

[6] Vanthienen, J., "50 Ways to Represent your Rule Sets," Business Rules Journal, Vol.  7, No. 1 (Jan.  2006), URL:  http://www.BRCommunity.com/a2006/b266.html  

# # #