=Paper=
{{Paper
|id=Vol-236/paper-1
|storemode=property
|title=Compliant and Flexible Business Processes with Business Rules
|pdfUrl=https://ceur-ws.org/Vol-236/paper3.pdf
|volume=Vol-236
|dblpUrl=https://dblp.org/rec/conf/caise/GoedertierV06
}}
==Compliant and Flexible Business Processes with Business Rules==
https://ceur-ws.org/Vol-236/paper3.pdf
94 Business Process Modeling, Development, and Support
Compliant and Flexible Business Processes with
Business Rules
Stijn Goedertier and Jan Vanthienen
Department of Decision Sciences & Information Management,
Katholieke Universiteit Leuven, Belgium
{myFirstName.myLastName}@econ.kuleuven.be
Abstract. 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 flexi-
bility. In particular, it is argued that flexible business process models
require business rules as a declarative formalism to capture the seman-
tics 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 flex-
ibility.
1 Motivation and Methodology
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 busi-
ness. 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 regu-
lation when we model business processes. However, because we lack an explicit,
BPMDS'06 95
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.
Criteria of Change
Abstraction level Subject of Change Properties of Change
Type Functional Extent
Instance Organizational Incremental
Behavioral Revolutionary
Informational Duration
Operational Temporary
Permanent
Swiftness
Immediate
Deferred
Anticipation
Ad hoc
Planned
Origin
Internal policies
External regulations
Fig. 1. A taxonomy of flexibility in business processes [2]
This paper is structured as follows. In section 2 we outline the relevant liter-
ature 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 sec-
tion 4 we indicate how the different BRACE building blocks related to different
96 Business Process Modeling, Development, and Support
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.
2 Related Work
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 pa-
per 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 informa-
tion that is required in a business interaction in terms of fact types, con-
straints 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 com-
mitments of agents in a business interaction, rather than modeling the im-
plementation of a process. In this context, the state space, or rather the
BPMDS'06 97
commitment space, contains the performances of agents and the commit-
ments 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.
3 The Origin of Change
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 verifica-
tion of compliance. In many cases, however, business regulation loses its general
meaning when internalized and made actionable in terms of business rules.
98 Business Process Modeling, Development, and Support
4 The Subject of Change
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-to-
cash 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 re-
lates 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-pays-
invoice, 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 busi-
ness rules [3], with some change in definitions.
4.1 Integrity Constraints
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.
4.2 Derivation Rules
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
BPMDS'06 99
“The conditions of an order
must match those of the
corresponding offer”
Is the order
accept
available-to-
yes
promise? Is the order
order order available-to- accept
yes no promise? yes
reject
no no
Does the order match the reject
corresponding offer?
inconsistent-with-
offer violation
Fig. 2. An integrity constraint
not appear in process models. It is up to de BPS system to autonomously deter-
mine 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.
“Loyal customers
get 10% discount”
invoice
Loyal invoice
customer? with 10% invoice
yes discount
accept accept
no regular
invoice
Fig. 3. A derivation rule
4.3 Deontic Assignments
Deontic assignments are statements of the powers, permissions and obliga-
tions 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].
100 Business Process Modeling, Development, and Support
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 as-
signments [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 permis-
sions. 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.
shipment-after-payment accept pay ship
payment-after-shipment accept ship pay
pay accept ship
pay ship accept
ship accept pay
ship pay accept
Fig. 4. Deontic rules impose partial order constraints
BPMDS'06 101
4.4 Reaction Rules
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].
shipment-after-payment payment-after-shipment
reaction timeout shipment reaction timeout shipment
timeout timeout
B UY ER
B UY ER
order pay order
pay
order refused order refused
ship
accept accept ship
SE LLE R
SE LLE R
payment
violation payment
reject reject violation
Fig. 5. Two sets of deontic assignments lead to two different process models
4.5 The Subject of Change
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
102 Business Process Modeling, Development, and Support
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; particu-
larly 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 perspec-
tive, 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 activ-
ities executed during the process. This is present in the activity type modeling
construct. The behavioral perspective defines, when and under which pre-
conditions 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.
5 The Abstraction Level of Change
Business rules lay down a lot of the semantics of business processes: the per-
missions 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 con-
sequence 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 re-
action 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.
6 Conclusion
Information systems systems must flexibly support business processes that at
the same time are compliant to the intra-organizational policies of the busi-
ness and the inter-organizational regulations the business has to observe. To
achieve business process flexibility, we need a more declarative approach in the
BPMDS'06 103
modeling of business processes. In this paper, it is informally, yet systemati-
cally 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.
References
1. Pine, B.: Mass Customization - The New Frontier in Business Competition. Har-
vard Business School Press, Boston, Mass. (1993)
2. Regev, G., Soffer, P., Schmidt, R.: Taxonomy of flexibility in business processes.
Produced as a result of the BPMDS’05 workshop. Available at http://lamswww.
epfl.ch/conference/bpmds06/taxbpflex (2005)
3. Wagner, G.: The agent-object-relationship metamodel: towards a unified view of
state and behavior. Inf. Syst. 28(5) (2003) 475–504
4. Ross, R.G.: Business Rule Concepts - Getting to the Point of Knowledge. Business
Rules Solutions, LLC; 2nd edition (2005)
5. Debevoise, T.: Business Process Management With a Business Rules Approach:
Implementing the Service Oriented Architecture. Business Knowledge Architects
(2005)
6. Bider, I., Khomyakov, M., Pushchinsky, E.: Logic of change: Semantics of object
systems with active relations. Autom. Softw. Eng. 7(1) (2000) 9–37
7. van der Aalst, W.M.P., Weske, M., Grünbauer, D.: Case handling: a new paradigm
for business process support. Data Knowl. Eng. 53(2) (2005) 129–162
8. Dietz, J.L.G., Halpin, T.A.: Using DEMO and ORM in Concert: A Case Study.
In: Advanced Topics in Database Research, Vol. 3. (2004) 218–236
9. Bussler, C.: The role of b2b protocols in inter-enterprise process execution. In:
TES ’01: Proceedings of the Second International Workshop on Technologies for
E-Services, London, UK, Springer-Verlag (2001) 16–29
10. Chopra, A.K., Singh, M.P.: Commitments for flexible business processes. In:
AAMAS, IEEE Computer Society (2004) 1362–1363
11. Rosenberg, F., Dustdar, S.: Business Rules Integration in BPEL - A Service-
Oriented Approach. In: CEC. (2005) 476–479
12. Goedertier, S., Vanthienen, J.: Rule-based business process modeling and execu-
tion. 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)
13. Orriëns, B., Yang, J., Papazoglou, M.P.: A rule driven approach for developing
adaptive service oriented business collaboration. In: ICSOC. (2005) 61–72
14. Yolum, P., Singh, M.P.: Reasoning about commitments in the event calculus:
An approach for specifying and executing protocols. Annals of Mathematics and
Artificial Intelligence 42(1-3) (2004) 227–253
15. Shanahan, M.: Solving the frame problem: a mathematical investigation of the
common sense law of inertia. MIT Press, Cambridge, MA, USA (1997)
16. Goedertier, S., Vanthienen, J.: Business Rules for Compliant Business Process
Models, 9th International Conference on Business Information Systems, BIS2006,
Klagenfurt, Austria May 31 June 2, 2006, Proceedings. Lecture Notes in Computer
Science (2006) forthcoming.