When modeling business processes, we often implicity think of internal business policies and external regulations. Yet to date, little attention is paid to avoid hard-coding policies and regulations directly in control-flow based process models. The standpoint of this analysis 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. Four kinds of business rules can be used as a starting point to generate less complex control-flow-based business process models. It is shown that these different kinds of business rules relate to different perspectives in the taxonomy of business process flexibility.
Socio-economic factors like globalization and liberalization have made business environments ever more complex and prone to change. Change and complexity are often mutually inductive couplings such that companies that embrace change in their business policies are often compelled to bring in extra complexity and vice versa. For instance, companies that want to adapt to ever changing market conditions often have to bring in the complexity of customer-tailored service offerings on a massive scale [1]. But change also comes from the regulations imposed by different kinds of stakeholders. In this case the complexity stems from the increasing pressures on companies not only to comply but also to guarantee compliance with legislation and quality norms. To foster change and to guarantee compliance, companies often automate their business processes. This setting imposes a myriad of business requirements for flexible business process support.
Against this setting, it is useful to consider the smallest unit of business change: a business rule change. Business rules are atomic, formal expressions of business policy and regulation that define or constrain some aspect of business. In this paper, we argue that business rule modeling plays an important role in achieving business process flexibility. In fact, business rules and business processes are two sides of the same coin: whenever the rules change, processes may change accordingly. We often implicitly think of business policy and regulation when we model business processes. However, because we lack an explicit, declarative formalism to capture the semantics of regulation and policy, business processes are difficult to change.
The contribution of this paper is a framework for business process modeling based on business rules, called EM-BRACE: Enterprise Modeling using Business Rules, Agents, Activities, Concepts and Events. Business policy and regulation are internalized and made explicit in terms of the BRACE building blocks. In this paper we indicate how four kinds of business rules can be used as a starting point to generate less complex control-flow-based business process models.
In the working paper prepared for the BPMDS'06 workshop, Regev et al. suggest a taxonomy of flexibility in business processes [2]. This taxonomy is depicted in Fig. 1. Regev et al. define business process flexibility as the capability to implement changes in the business process type and instances by changing only those parts that need to be changed and keeping other parts stable. The methodology of the EM-BRACE framework leads to more flexibility in business processes: business policy and regulation become traceable in terms of business rules such that companies can more easily manage complexity and keep track of change. Because the methodology does not hard-code the logic of policy and regulation, control-flow-based process models in languages such as the UML Activity Diagram or the Business Process Modeling Notation (BPMN) are less complex and more fit to change. A taxonomy of flexibility in business processes [2] This paper is structured as follows. In section 2 we outline the relevant literature on business rules and declarative constructs in business process modeling. The remainder of the paper has the structure of the above depicted taxonomy of flexibility in business processes 1. In section 3 we argue that the origin of business process change is an important and generic property of change. In section 4 we indicate how the different BRACE building blocks related to different BPMDS'06 perspectives in the taxonomy. We also give examples of how different kinds of business rules can be used to simplify control-flow-based process models. Finally, in section 5 we stress that business rules leave room for instance-level flexibility.
Many authors recognize the value of business rules in requirements analysis and system design. As a consequence, many definitions and classifications of business rules exist in the literature, of which Wagner gives an overview [3]. We adapt Wagner's definition and define business rules as atomic, formal, expressions of both business policy and business regulation that define or constrain some aspect of business. Wagner categorizes business rules in four basic types [3]: integrity constraints, derivation rules, reaction rules and deontic assignments. In this paper we build on this categorization to demonstrate the role of business rules in business process modeling.
The interest in the confluence of business rule modeling and business process modeling originally stems from practitioners [4] [5]. In the academic community, however, there has been a parallel evolution towards declarative business process modeling. Without going into detail, we mention the following ideas:
-state orientation defines a process as a trajectory in a state space. Bider et al. define a state space in terms of constructs that reflect the "relevant part of the business world" [6]. van der Aalst et al. introduce the case handling paradigm, as a new data-driven paradigm for business process support [7].
Much like the state-oriented approach to business process modeling, case handling focusses on what can be done to achieve a business goal. The valid movements in state space are based on the information already available, not on the activities already executed. Linked to the idea of state orientation, Goal orientation requires process models to include the goal of the business process. A planner can be used to construct a valid trajectory to the goal state. -Agent orientation requires the modeling of both internal and external agents to a business process. Internal agents perform activities in the business process. External agents communicate by means of business events. -Fact orientation aims at formally and conceptually modeling the information that is required in a business interaction in terms of fact types, constraints and derivations. Dietz and Halpin indicate that business processes can be viewed as production and coordination acts performed by agents [8].
The state of the business interaction is then defined as a set of production and coordination facts that populate the fact types of the business domain. -Commitment-awareness analyses business process modeling from a third person perspective, rather than from a first person perspective [9]. Singh et al. demonstrate [10] how flexibility can be achieved by modeling the commitments of agents in a business interaction, rather than modeling the implementation of a process. In this context, the state space, or rather the commitment space, contains the performances of agents and the commitments that result from it.
To achieve business process support that is flexible and compliant to business policy and regulations, an architectural context is required in which business rules are enforced during business process enactment. Keeping business processes and business rules separate at modeling time, raises the problem of how to link the enforcement of business rules, the manipulation of data and the enactment of processes at execution time. Service Oriented Architectures can be used to integrate the functionality of different applications, process support and business rule support while maintaining a strong de-coupling [5]. Rosenberg and Dustdar show how business rules can be integrated in the Business Process Execution Language (BPEL) using a rule interceptor service that intercepts each incoming and outgoing BPEL web service call to automatically apply business rules [11]. Goedertier and Vanthienen show how a process support service can enact a process model by decomposing the processing of each business event as a number of consecutive queries on an inference engine [12]. These works do not investigate the role of deontic assignments in business process modeling. Business rules are also present in the Business Collaboration Development Framework (BCDF) of Orriëns, Yang and Papazoglou [13]. This framework strives for adaptability in business collaboration through web services using development rules -which include business rules -for domain analysis , management rules for validation and verification and derivation rules for model transformation.
Business process change originates either from internal business policy change or external business regulation change. For this reason the origin of change has been added to the taxonomy in figure 1. On the one hand, business policies are internally defined and come from the intended strategies of management, the tactical decision policies of middle management or the operational procedures of the personnel. For instance, an order acceptation policy, a discount policy, a procedure to deal with doubtful debtors,... are examples of business policies. Business policy has to be made explicit and actionable, preferably in terms of business rules.
Business regulations, on the other hand, are externally imposed regulations such as business protocols, legislation, long-term contracts, quality norms,... For instance, a trade-via-a-trusted-intermediary business protocol, a value-added-tax bill, a long-term sales contract with fixed prices or even ISO 9000 are examples of business regulation. Business regulation often brings about change in the business process of several business partners in a business interaction. Business regulation in the form of business rules can become a standard specification in a business community, which can stimulate reuse or enable automatic verification of compliance. In many cases, however, business regulation loses its general meaning when internalized and made actionable in terms of business rules.
It is outside to scope of this paper to provide clear cut semantics for the modeling constructs of the EM-BRACE framework. Instead, we will consider an order-tocash business process as a running example and try to clarify to role of business rule modeling in achieving business process flexibility. We will indicate how each subject-of-change perspective in the taxonomy of business process flexibility relates to modeling constructs in the EM-BRACE framework. In an order-to-cash business process, the following ACE building blocks can be distinguished:
-Roles of agents: buyer, seller -Activity types: to place an order, to accept an order, to refuse an order, to pay an invoice,... -Concepts: order, age of buyer, invoice, discount,... -Event types: buyer-places-order, seller-accepts-order, buyer-paysinvoice, seller-ships-goods...
Corresponding to the ACE building blocks four kinds of business rules can be distinguished: integrity constraints, derivation rules, deontic assignments and reaction rules. This classification is adopted from Wagner's classification of business rules [3], with some change in definitions.
Integrity constraints are logic 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. We often implicitly think of integrity constraints and model them as preconditions or data validation rules in the process model. For instance, in the left-hand side of Fig. 2 the data validation rule to enforce that "customers aged under 18 cannot place an order" is hard-coded in the BPMN diagram. However, integrity constraints should remain autonomous business rules. During business process enactment, the BPS system should autonomously decide when it is to guard the enforcement of integrity constraints. This approach simplifies the modeling of business processes, as is depicted in the right-hand side of Fig. 2.
Derivation rules are logic 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 gateways in BPMN models. For example, the left-hand side of Fig. 3 depicts the logic that "loyal customers receive 10% discount". However, the logic of derivations should "The conditions of an order must match those of the corresponding offer"
Is the order available-topromise?
Fig. 2. An integrity constraint not appear in process models. It is up to de BPS system to autonomously determine when a derivation rule is applicative. This approach simplifies the modeling of business processes, as is depicted in the right-hand side of Fig. 3. Many BPS systems already provide a similar kind of flexibility. Yet to our knowledge the scope has remained limited to the use of production rules and implementations have shown a strong coupling between process and rule environment in which it is often the case that the process (execution) model makes explicit calls to a rule service.
Deontic assignments are statements of the powers, permissions and obligations of internal and external agents. Deontic assignments specify data access rights or the obligations and permissions to the performance of activities in a business protocol. Especially the latter kind of deontic assignment is particularly relevant to the modeling of business protocols for business processes. Business protocols describe business processes from a third-person perspective, rather than from a first-person perspective [9].
Yolum and Singh have shown how how commitments can be used in the modeling of business protocols using formal logic [14] [10] based on the Event Calculus, for which Shanahan provides suitable axiomatizations [15]. Similarly, we have developed a formal language, called PENELOPE (Process ENtailment from the ELiciteation of Obligations and PErmissions) to express deontic assignments [16]. Our language is different from Yolum and Singh's mainly because it is designed with a purpose to generate compliant sequence-flow-based process models from a rule set of permissions an obligations. To this end, we we consider activities rather than propositions to be the object of obligations and permissions. Moreover we allow to explicitly define deadlines on the performance of activities in terms of the performance of previous activities. Not performing an obligation within due date leads to a violation, for which a protocol might or might not provide a so-called reparation solution.
It is outside the scope of this paper to further discuss PENELOPE. However, we give an example to demonstrate the intuition behind deontic assignments. Suppose an order-to-cash business process can occur according to two distinct terms: payment-after-shipment or shipment-after-payment. These terms could be specified by the following sets of deontic assignments:
-payment-after-shipment "When the buyer places an order, the seller must either accept or reject it." "When the seller accepts an order, the seller must ship the goods." "When the buyer places an order, the buyer must pay within 30 days, after the seller ships the goods." -shipment-after-payment "When the buyer places an order, the seller must either accept or reject it." "When the buyer places an order, the buyer must pay within 30 days, after the seller accepts the order." "When the seller accepts the order, the seller must ship the order, after the customer pays."
It can be formally shown that these kind of permissions and obligations to the performance of an activity impose partial order constraints to the activities in a business processes [16]. Consider for instance the activities accept, pay and ship. Of the six sequential order relations, only one is acceptable to each set of deontic assignments, this idea is represented in Fig. 4. Both sets of deontic assignments lead to different process models, both for seller and buyer; these process models are displayed in Fig. 5. Reaction rules state which actions are to be undertaken, given the occurrence of a certain business event and the state of the process instance. For instance two gateways in Fig. 5 indicate that "orders that are available-to-promise are to be accepted". While deontic assignments describe behavior in the third-person, reaction rules describe behavior in the first-person; from the perspective of one of the agents that participates in a business interaction. Agents must not violate the obligations imposed by deontic assignments. But, by way of precaution, agents must foresee that other agents violate their obligations. For instance, when a seller accepts an order, it must foresee the possibility never to receive payment. This is represented in the business process models of Fig. 5 as intermediate timeout events. The reaction to a payment timeout 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." Goedertier and Vanthienen show how reaction rules can be used to model composite events and long-running activities and use the decision table formalism as a comprehensible way to elicit and represent a set of reaction rules [12]. Regev et al. suggest that the subject of change in business processes can be traced to five perspectives: the functional, the organizational, the behavioral, the informational and the operational perspective [2]. These perspectives are generic, and make as little assumptions as possible regarding modeling constructs. It is interesting to see how the constructs of the EM-BRACE framework relate to these perspectives. The functional perspective describes what the process has to do; particularly it defines the process goal. To mention the process goal, requires a definition of the state space. Rather than defining state space from a first-person perspective, it is more meaningful to describe to goal of an agent from a third-person perspective [10]. For example, in an order-to-cash process the goal of the buyer is the performance of a ship activity by the seller, whereas the goal of the seller is the performance of the pay activity by the payer. However, a goal can only be considered an end state if no further obligations or permissions rest with the agents of the business protocol. The operational perspective describes activities executed during the process. This is present in the activity type modeling construct. The behavioral perspective defines, when and under which preconditions activities are performed. Both deontic assignments and reaction rules pertain to this perspective. In the informational perspective the information that is exchanged between activities (and agents) is defined. The information is modeled in terms of business concepts. Both integrity constraints and derivation rules have to do with business concepts, and thus also relate to the informational perspective on process change. The organizational perspective describes who participates in which roles in the process. This is modeled in terms of agents and roles.
Business rules lay down a lot of the semantics of business processes: the permissions and obligations of agents, the semantics of business concepts and the reaction to events. This could create the impression that business rules could only support process type evolution [2]. The only way to change a business process, is by changing the underlying business rules of a process model. By consequence process change only applies to new process instances. However, business rules might leave some freedom of choice not to enact a business process model in the normal way, for instance, to cope with exceptional situations. This is called instance evolution [2]. This is possible, because integrity constraints and reaction rules should not always have the modality of unbendable rules. Rather, integrity constraints and reactions rules could have the modality of guidelines that give direction, but also allow flexibility, freedom of choice to steer the process and to deal with exceptional situations.
Information systems 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 more declarative approach in the modeling of business processes. In this paper, it is informally, yet systematically demonstrated that we should not hard-code internal business policy and external regulation into control-flow-based process models. Instead, we need the concept of the smallest unit of business logic, a business rule, to capture the semantics of policy and regulation. We have shown how each of Wagner's four kinds of business rules can be used as a starting point to generate less complex control-flow-based business process models.