L.R. on Integration of business rules and business processes

M. zur Muehlen and M. Indulska. Modeling languages for business processes and business rules: A representational analysis. Information Systems, 35(4):379–390, Elsevier, 2010.

Early work on the integration of business rules and business processes appeared shortly after the introduction of the rule modeling concept [13,14]. Krogstie et al. [16] were the first to suggest that business process and rule modeling approaches should be merged to improve the capture of temporal information for Information Systems (IS) development. They presented a top-down approach for model specification that involves the use of the External Rule Language for specification of process logic at the lowest level of decomposition. McBrien and Seltveit [20] further enhanced this concept by defining the structure of rules within the process model. Knolmayer et al. [14] refined process modeling and linked the resulting models to workflow execution through layers of Reaction Business Rules. Kappel et al. [13] use Reaction
Business Rules to model the coordination in workflow systems. Kovacic [15] developed a meta-model that represents important business constructs (goal, process, activity and events) and technical constructs (data objects, software components, actions in Information Systems). He demonstrates how rules can link these two categories of constructs. Charfi and Mezini [1] argues that business rules are often hard-coded into web services and proposes a hybrid approach of separating business processes and business rules. Meng et al. [21] introduced a dynamic workflow management system for modeling and control- ling the execution of inter-organizational business pro- cesses. The system uses an event- and rule-server to trigger business rules during the enactment of workflow processes in order to enforce business constraints and policies.
While the integration of rule and process modeling has been the subject of some investigation in the research community, anecdotal evidence shows that organizations struggle to effectively capture business processes and rules. In a recent study of the representational capabilities of the Business Process Modeling Notation (BPMN), we found that organizations frequently supplement their BPMN process models with textual annotations of busi- ness rules [27]. This practice introduces problems regard- ing the consistency, reuse, and enforcement of rules – problems that are acknowledged by some of the organiza- tions using this technique.
The need to improve the representation of business rules within process model diagrams is apparent, yet little is known about which representation aspects, if any, are unique to each of the two types of modeling languages. Previous work by Recker et al. [26] has identified a general lack among process modeling languages to adequately represent business rules. Similarly, Green and Rosemann [6] found limitations with respect to modeling business rules in their BWW-based investigation of all five views of Architecture of Integrated Information Systems a popular enterprise architecture framework.
Rule modeling languages are likely candidates to fill such gaps. An earlier study by Herbst et al. [9] suggests that rule specification languages should be considered as a potential addition to graphical representation languages when modeling for Information Systems design. While their analysis is not based on any formal framework, they suggest that many of the popular IS modeling techniques lack the ability to adequately represent business rules. The work of Rosemann et al. [29] suggests that the same shortcomings exist in the process modeling domain; hence, an integration of business rule and business process modeling approaches may help overcome these perceived shortcomings.
In order to effectively integrate graphical business process modeling approaches with business rule model- ing approaches, we need to understand their synergies and overlap. In our research, we were unable to locate any attempts to evaluate the expressiveness of rule modeling languages or their relationships to conceptual process modeling approaches. The only related work appears to be that of Lu and Sadiq [17] who compared graph-based and rule-based modeling approaches. Since their work was focused on workflow modeling in particular, rather than conceptual modeling in general, no specific rule modeling languages were considered. The authors used a set of workflow patterns [36] as a basis for the evaluation, and found, that rule- and graph-based modeling approaches had similar levels of expressiveness in terms of the control flows specified by the workflow patterns.

1   : A. Charfi, M. Mezini, Hybrid web service composition: business pro- cesses meet business rules, in: Paper presented at the Proceedings of the Second International Conference on Service Oriented Computing, New York, NY, USA, 2004.
6   : P. Green, M. Rosemann, Perceived ontological weaknesses of process modelling techniques: further evidence, in: Paper presented at the 10th European Conference on Information Systems, Gdansk, 2002.
9   : H. Herbst, G. Knolmayer, T. Myrach, M. Schlesinger, The specifica- tion of business rules: a comparison of selected methodologies, in: A.A. Verijn-Stuart, T.-W. Olle (Eds.), Methods and Associated Tools for the Information System Life Cycle, Elsevier, Amsterdam, 1994, pp. 29–46.
13 : G. Kappel, S. Rausch-Schott, W. Retschitzegger, Coordination in workflow management systems – a rule-based approach, in: W. Conen, G. Neumann (Eds.), Coordination Technology for Collabora-
tive Applications – Organizations, Processes, and Agents, 1364 ed., vol. 1364, Springer, Berlin, 1998, pp. 99–119.
14 : G.F. Knolmayer, R. Endl, M. Pfahrer, Modeling processes and
workflows by business rules, in: W.M.P. van der Aalst, J. Desel, A. Oberweis (Eds.), Business Process Management, Models, Techni- ques, and Empirical Studies, vol. 1806, Springer, London, 2000, pp. 16–29.

15 : A. Kovacic, Business renovation: business rules (still) the missing link, Business Process Management Journal 10 (2) (2004) 158.

16 : J. Krogstie, P. McBrien, R. Owens, A.H. Seltveit, Information systems development using a combination of process and rule-based approaches, in: R. Andersen, J.A. Bubenko Jr., A. Solvberg (Eds.), Third International Conference on Advanced Information Systems Engineering (CAiSE ‘91), Springer, Trondheim, Norway, 1991, pp. 319–335.

17 : R. Lu, S. Sadiq, A survey of comparative business process modeling approaches, in: Paper presented at the Proceedings of the 10th International Conference on Business Information Systems, Poznan, Poland, 2007.
20 : P. Mcbrien, A.H. Seltveit, Coupling process models and business rules, in: Proceedings of the IFIP 8.1 WG Conference on Information Systems Development for Decentralized Organizations, 1995.
21 : J. Meng, S.Y.W. Su, H. Lam, A. Helal, Achieving dynamic inter- organizational workflow management by integrating business processes, events and rules, in: Paper presented at the Proceedings of the 35th Annual Hawaii International Conference on System Sciences System Sciences, HICSS 2002, Waikoloa, HI, 2002.
26 : J. Recker, M. Indulska, M. Rosemann, P. Green, Do process modelling techniques get better? A comparative ontological analysis of BPMN, in: Paper presented at the Proceedings of the 16th Australasian Conference on Information Systems, Sydney, Australia, 2005.
27 : J. Recker, M. Indulska, M. Rosemann, P. Green, How good is BPMN really? Insights from theory and practice, in: Paper presented at the 14th European Conference on Information Systems, Goeteborg, Sweden, 2006.
29 : M. Rosemann, J. Recker, M. Indulska, P. Green, A study of the evolution of the representational capabilities of process modeling grammars, in: E. Dubois, K. Pohl (Eds.), Advanced Information Systems Engineering – CAiSE 2006, vol. 4001, Springer, Luxem- bourg, Grand-Duchy of Luxembourg, 2006, pp. 447–461.
36 : W.M.P. Van Der Aalst, A.H.M. Ter Hofstede, B. Kiepuszewski, A.P. Barros, Workflow patterns, Distributed and Parallel Databases 14 (1) (2003) 5–51.

Types of business rules

M. zur Muehlen and M. Indulska. Modeling languages for business processes and business rules: A representational analysis. Information Systems, 35(4):379–390, Elsevier, 2010.

Different types of business rules can be distinguished:

• Integrity rules express constraints. These rules typically define the acceptable relationship between data ele- ments. For example, each project must have one and only one project manager.
• Derivation rules express conditions that result in conclusions. These rules define the validity of facts and can be used to infer new facts based on known facts. For example, platinum customers receive a 5% discount. John Doe is a platinum customer. As a conclusion, John Doe receives a 5% discount.
• Reaction rules (also known as Event-Condition- Action (ECA) rules, alternative-action rules, or post- conditions) specify a trigger that activates the evaluation of the rule, a condition that is evaluated, and a subsequent activity that will be carried out if the specified condition is met; for example, the evaluation of a reaction rule is triggered as soon as a new invoice is received. If the invoice amount is more than $1000 then a supervisor review is initiated.
• Production rules (also known as condition, action rules) are similar to reaction rules, but do not specify a particular circumstance in which the evalua- tion takes place; For example, if there are no defects in the last 10 widgets, the entire batch is quality approved.
• Transformation rules restrict the state changes of objects; for example, an employee’s age can change from 30 to 31, but not from 31 to 30.

G. Wagner, Rule modeling and markup, in: N. Eisinger, J. Maluszynski (Eds.), Reasoning Web, 3564 ed., vol. 3564, Springer, Berlin, Msida, Malta, 2005, pp. 251–274.

summary: Law, Logic and Business Processes

G. Governatori. Law, logic and business processes. In Requirements Engineering and Law (RELAW), 2010 Third International Workshop on, pages 1 –10, sept. 2010.

Compliance is a relationship between two sets of specifications, business processes and regulations. To be able to determine the compliance one needs to have: a formal representation of the business process, a formal representation of the regulations, and a common framework to interface the two formal languages. Enterprises are more dependent on PAIS (process aware information systems), and business processes are increasingly constrained by the legislative and regulatory framework in which they operate. Research should “address the issue of how to incorporate techniques to handle normative requirements, and these techniques should be conceptual, in the sense that they should provide notions and construction as close as possible to the concepts they intend to models”.

The author believes that there are three important features to be able to model compliance, which are defeasibility, the deontic effect of a norm, and whether the effects of a norm are persistent. “Defeasibility, the notion that a conclusion can be withdrawn, in case of additional information that allow to conclude the opposite, is very important in modelling normative reasoning where we can combine different sources for norms. This is particularly suitable for processes, where we can derive plausible conclusion based on the information provided, but when more data becomes available the conclusion can be changed. The deontic effects (obligations, permissions, prohibitions) are essential to capture compliance. They specify what is permitted, forbidden and required to fulfill the normative requirements. Finally the features about the persistency of normative effects allow us to define different types of obligations, with different conditions for their fulfillment of violation. These features have the effect that we are able to model different types of common scenarios”.

The paper proposed a new language “Process Compliance Language (PCL)” based on enhancing an older solution FCL (formal contract language) from another paper (“An algorithm for business process compliance”), it generalizes and extend FCL. First it distinguishes between achievement obligation (happen at least once before deadline) and maintenance obligation (continues). It also shows that achievement obligations can be persistent (must happen even after deadline) or non-persistent (once the deadline occur the obligation no longer holds). Also achievement obligations can be preemptive (can happen before the trigger) or non-preemptive (must only happen after the trigger). PCL provides a way of writing regulations that if an obligation was violated the rule will show what to do next it uses the non-boolean connective ‘⊗’ to link the obligation to another obligation that would be enforced if the first one was violated (e.g. Oa,π A ⊗ OpB ⊗ OmC means that the primary provision is an achievement, persistent, obligation to do A, but if A is not done, then we have a punctual obligation to do B. If B fails to be realised, then we obtain a maintenance obligation to do C). The language also provides superiority relation (≺) determines the relative strength of two rules, to solve potential conflicts. The process to build the rules model in PCL is: 1- write regulations using the formal language represented in here, 2- remove any redundant rules, 3- label and detect conflicts.

The paper then explained business process models and it main components, and gave an example process from the banking field and showed it process model and how to write the related rules using PCL. Then finally gave a procedure to check wither execution paths of a process are compliant with the PCL and thus with the normative system modeled by the PCL specifications. The procedure is: first identify set of effects for all the tasks in the process. Second, for each task determine the normative position (obligations, permissions, prohibitions). Finally, for each task compare the effects of the tasks and the obligations accumulated up to the task. If an obligation is fulfilled by a task, discharge the obligation, if it is violated signals this violation. If it is not fulfilled nor violated, keep the obligation in the stack of obligations and propagate the obligation to the successive tasks.

Governatori in this paper presented a new language PCL, which can be used to write regulations and rules. The language has the ability to show different types of obligations and also handle violations. The language can also be used to avoid conflict if they were detected in the writing stage, using the consistent writing process. The paper only showed how this language can handle rules that say what must be done, but do not have the ability to follow a rule that say how to do it (the author claim that the language has the ability and will be explained in another paper). The paper also provided an algorithm that detects compliance between a business process and regulations written in PCL. Although PCL can handle various types of obligations it did not show how to handle permissions and prohibitions.

why we need to integrate security in BPM

M. zur Muehlen and M. Indulska. Modeling languages for business processes and business rules: A representational analysis. Information Systems, 35(4):379–390, Elsevier, 2010.

 
Process modeling languages and security policies languages are both used to document organizational policies and procedures. While process modeling languages typically describe a procedural sequence of activities, including decisions and concurrency, security policy languages often rely on a declarative description of security conditions, and constraints that need to be followed. To date, their synergies and overlap are under researched. Understanding the relationship between the two languages types would allow organizations to maximize synergies, avoid content duplication, and thus reduce their overall effort.

G. Governatori. Law, logic and business processes. In Requirements Engineering and Law (RELAW), 2010 Third International Workshop on, pages 1 –10, sept. 2010.

S. Sadiq and G. Governatori, “Managing regulatory compliance in business processes,” in Handbook of Business Process Management, J. van Brocke and M. Rosemann, Eds.    Berlin: Springer, 2010, vol. 2, ch. 8, pp. 157–173.


Nowadays more and more businesses in all sectors relay and heavily depends on their process aware information systems. These systems are now essential to control, administer and enact all core business activities. Furthermore, failure to follow security policies is no longer an option. This means that research in business processes must now address the issue of how to incorporate techniques to handle security policies requirements, and these techniques should be conceptual, in the sense that they should provide notions and construction as close as possible to the concepts they intend to models. Until now ad-hoc solutions appear as the only option for otherwise routine situations. This leads to increased cost, and this is one of the reasons why security policies are still seen as burden on a process, instead of an opportunity to improve the performance of it.

S. Goedertier and J. Vanthienen. Designing compliant business processes with obligations and permissions. In J. Eder and S. Dustdar, editors, Business Process Management Workshops, volume 4103 of Lecture Notes in Computer Science, pages 5–14. Springer, 2006.

Business process languages such as UML Activity Diagrams, BPMN, Event- Process-Chains, etc. are most often based on the control-flow paradigm, and define an explicit order relation between the activities in the process. These order relations even occur in the case handling paradigm, in which a preferred or normal control-flow is defined between activities. What is lacking is a declarative approach that makes the partial order relations due to security and legal requirements more explicit.

what we need to enforce Sec. into BPM

G. Governatori. Law, logic and business processes. In Requirements Engineering and Law (RELAW), 2010 Third International Workshop on, pages 1 –10, sept. 2010.

It is a relationship between two set of specifications, where one the target does not result in violation of the source. This means that to determine whether a business process is appling the relevant security policies, one has to have:
1) a formal specification of the business process;
2) a formal specification of the (relevant) security policies;
3) a common framework to interface the two sets of specifications.
 

G. Governatori and Z. Milosevic. A formal analysis of a business contract language. Int. J. Cooperative Inf. Syst., 15(4):659–685, 2006.

A formal language for security policies should be conceptual, allowing its users to focus exclusively on aspects related to the content of the policy, ignoring implementation aspects.

Summary: Framework for Business Process and Rule Integration: A Case of BPMN and SBVR

R. Cheng, S. W. Sadiq, and M. Indulska. Framework for business process and rule integration: A case of bpmn and sbvr. In W. Abramowicz, editor, BIS, volume 87 of Lecture Notes in Business Information Processing, pages 13–24. Springer, 2011.

“Integrating the outputs of the two modeling approaches is a challenging task. First, business process models tend to be visual in nature. Business rules, however, tend to be text-oriented. Second, they have different composing elements. Third, they are designed for different purposes - process models describe how things should happen, whereas business rules describe what should happen. Finally, the overlap and inconsistencies between business process models and business rules also presents a significant challenge”. This paper is about a framework that integrates BPMN (Business Process Modeling Notation 2.0), process modeling language, and SBVR (Semantics of Business Vocabulary and Business Rules), rules modeling language.

Most available frameworks follow a top-down approach, and that integration should happen in the design stage, which is correct but not realistic. As in reality most organisations already have existing processes’ models and rules’ models that are separate, and the real problem facing organisations is integrating these existing models. That’s why a bottom-up approach is required, where integration happens in analysis stage. “The bottom-up integration framework is built around a collection of mapping methods that provide distinct ways in which overlap and consistency (or lack of) between processes and rules can be studied”.

Integration framework have two main aspects; semantic and structural aspects. Semantics aspects are about providing a reference that can provide a mapping between the two languages terms. Structural aspects are dealing with how the two languages have different structures. This paper only looked into structural aspects.

XML Process Definition Language (XPDL) was used as a canonical intermediate language to bridge the gap between BPMN, a visual process modeling approach, and SBVR, a text based business rule’s modeling language. Because, it is standardized and well supported, also it has the ability to transfer BPMN graphical notations into text representation.

To provide a mapping, both languages have to be broken down to the main components. SBVR was brought down to Name, Term, Verb, and four types of keywords. While BPMN consist of: activities, events, gateways, and participants. XPDL is used to translate each one of these BPMN components into XPDL tags and then mapped into SBVR component (a table is provided in the paper). The proposed approach do not have a way to present the model operation in BPMN except using ‘must’ or ‘it is obligatory’, which is considered a limitation of the solution. The paper also provided a car sale process and its business rules to demonstrate the proposed solution and prove its effectiveness.

in L.R.:

Cheng et al. in provided a bottom-up approach to integrate process models and business rules models in an analysis stage. There approach was specific to integrating BPMN process models with SBVR rules models. It used XPDL to translate the BPMN diagrams to text representation and then used these tags to map the business rules models, and finally producing a new model that include both the process and the rules. Even thought the approach was applied to BPMN and SBVR, but the idea can be generalized to other languages. A limitation to the approach, that it was only able to represent BPMN operations using either ‘must’ or ‘it is obligatory’. The approach did not invent a new language. It made use of XPDL and its ability to translate BPMN diagrams into XML tags. The main contribution was providing a list of the main components of the process language (BPMN) and the rules language (SBVR), and using XPDL to map these components to each other.

Challenges in integrating BP models and regulations

 

R. Cheng, S. W. Sadiq, and M. Indulska. Framework for business process and rule integration: A case of bpmn and sbvr. In W. Abramowicz, editor, BIS, volume 87 of Lecture Notes in Business Information Processing, pages 13–24. Springer, 2011.

"Integrating the outputs of the two modeling approaches is a challenging task. First, business process models tend to be visual in nature, with most of the relevant information represented graphically. Business rules, however, tend to be text-oriented. Thus, integration of the outputs of the two approaches requires an information exchange format with minimal information loss. Second, process models differ from business rules fundamentally as they have different composing elements. Third, they are designed for different purposes - process models describe how things should happen, whereas business rules describe what should happen. Finally, the overlap and inconsistencies between business process models and business rules also presents a significant challenge. In particular, a set of criteria is required that helps a business analyst to resolve identified overlaps and inconsistencies in a satisfactory manner."