The front page of this report contains an image of an inukshuk. The word inukshuk means ‘something which acts for or performs the function of a person’. Inukshuks are landmarks which can be found in the arctic region of North America. They were formerly used by Eskimos to navigate through the landscape. An inukshuk points to the next inukshuk and provides all necessary information about the route, such as warnings or places to hunt for food. In between inukshuks the traveler is on its own and deals with problems along the way. An experienced traveler does not need any help with this.
A comparison can be made with how organizations operate1. We can do much of our day to day work without instructions. Every worker is experienced in his work and can perform most of his activities autonomous. However, to navigate through the whole organizational process, to communicate with other people or increase performance, we need guidance along the way.
In order to develop the guidance needed, managers, consultants, process designers and other business people somehow try to capture the whole organization in so called process models. This can take up months of work and when finished the organization is already different then at the start. Therefore, this way of process analysis is not as effective as intended.
The research presented in this document is about focusing on the ‘inukshuks’ of an organization. It is about how to provide as much guidance to business workers as needed, while maintaining as much flexibility as possible.
1
READING ADVICE
From my own experience I know how difficult it can be to find the relevant and interesting parts within a report of someone else, especially when you do not have much time to spend. Therefore I added this reading advice in order to determine where to start reading.
Reading advice based on time
If this report can only take a few minutes of your time, please read the management summary at page v.
10’
For 30 minutes of your time I advice to read the introduction (p. 1) for a sense of urgency of this research and to read the conclusion (p. 63) to take note of the contribution.
30’
In one hour a more detailed understanding of the value of this research can be acquired. Therefore I advice to first read the introduction (p. 1), after which the sections 3.2 Business rule approach (p. 14) and 3.3 Rule‐based process management (p. 18) explain how the issue as described in the introduction can be solved. Then read section 4.2 Prior research (p. 28) where prior research in the field of rule‐based process management is described. Finally the sections 4.4 (p. 35) and 5.4 (p. 48) provide the main outcome of this research, which is related to the central research question in the overall conclusion at page 63. 1h Reading advice based on interest research method If you are interested in the way this research is performed, please read chapter 2 Research design. This section describes the method that is used to realize the outcome of this research.
For people who are already familiar with the business rule approach and rule‐based process design, the rule‐based process model and the business concept model might be interesting. The result of the modeling work is the core of this research. These are provided in the chapters 4 Rule‐based process model (p. 25) and 5 Business concept model (p. 37).
resulting models
For those who are interested in the background and related work of rule‐based process design, please read chapter 3 Business rule approach (p. 11) and the sections 4.1 Process design (p. 25) and 4.2 Prior research (p. 28).
related work
The demonstrator, which is part of the deliverables of this research, is presented and explained in chapter 6 Proof‐of‐concept (p. 51). However, to fully understand the design specifications underlying the implementation of the demonstrator, the chapters 4 Rule‐based process model (p. 25) and 5 Business concept model (p. 37) are essential.
ACKNOWLEDGEMENTS
This report is the final deliverable of my Master’s thesis project of the program Technology Management at the University of Groningen. I performed a research at TNO ICT in Groningen in the field of rule‐based process management. In random order, I would like to thank the following people who helped me during the project.
First, I would like to thank my supervisors at the University of Groningen for their guidance and feedback. It is my professor George Huitema who pointed at TNO as a company where I could conduct a research project. Halfway the project, assistant professor Hans van Uitert joined as second supervisor. George and Hans, thank you for your time and knowledge. Furthermore, I thank my colleagues, fellow interns and the organization of TNO for providing me a nice working environment. I can recommend TNO ICT for all those who are looking for an internship. During the past seven months, I shared an office with a continuous flow of interns. Byron, Bart, Herman, Rick, Bram, Tim, Wouter, Gauke, Wim, Siep and Tim, good luck to you all. Special thanks to my supervisor at TNO, Rieks Joosten. You introduced me in the field of claims‐based working, rule‐based process management and many other topics you are working on. I really enjoyed your enthusiasm and passion for the matter we were working on. It is because of our weekly discussion sessions on Mondays and Fridays, that I was able to do the amount of work I present in this report. I am confident that your vision on how information systems are designed in the future will become reality.
I received a lot of feedback on my draft versions. For that I thank Arjen Poppinga (fellow student), Wouter Lueks (fellow intern), Dick Schaap (assistant professor Business Processes at the University of Groningen) and of course my supervisors. Furthermore, I thank Jeroen Broekhuijsen, Daniël Boonstra and Gerben Broenink (all three working at TNO) for their contribution during the discussion sessions when talking about my research.
Finally, I would like to thank my family and friends for their faith, support and patience. In particular my parents and Marlies for being there.
MANAGEMENT SUMMARY
This report is the final deliverable of my Master’s thesis project performed at TNO ICT in Groningen, The Netherlands. The research presented in this report is about business process design and in particular about how to design IT‐support systems that perfectly fit business requirements. The following sections provide a summary of the report by indicating a problem of today’s business process design and providing the main results that offer a solution.
For process designers it is important to specify processes in an unambiguous way in order to guide business users to perform work as the design intends to. An unambiguous specification is even more important when designing IT‐support systems, because when process designers are not capable to specify exactly what results a process should deliver, IT‐engineers will not be able to meet the requirements as meant by the business. Often, IT‐support systems do not meet their business requirements or are not capable of adapting to changes in the business requirements. This implies a problem regarding the agility of an organization when their primary business processes mainly depend on (or consist of) IT‐support systems.
A business rule approach towards an organization’s business process management offers a solution to this problem of inflexibility. In order to design business processes according to a business rule approach (i.e. designing rule‐based processes), a conceptual understanding is needed about the idea behind rule‐based processes. This report provides a framework which elaborates on the main principles of rule‐based process design, thereby allowing for such a conceptual understanding. The framework consists of a rule‐based process model and a business concept model. These models describe the basic ideas of rule‐based process design and they are explained briefly in the following sections. Rule‐based process model Processes are the way in which organizations coordinate all the work that needs to be done to do business. This is done by precisely specifying what a process delivers (post condition) and on which conditions (pre‐ and boundary conditions). These conditions are formulated in terms of business rules. In addition, a structure of (sub) processes is used to divide the whole business process into pieces that can be handled within a certain scope. By precisely specifying and scoping processes, it is possible to design processes that can be interpreted unambiguous by both business users and computers. This enables the possibility to develop IT‐support systems that meet the requirements of the business.
Business concept model
The business concept model elaborates on the data perspective as mentioned in the previous section and in particular on how business rules are evaluated. A business concept has a specific meaning within a certain business context. For example, a valuable customer can have different meanings within different organizations. The meaning of a business concept is provided by its assigned business rules and attributes. A business rule could for example state that a customer that orders products for more than € 1000 per day is rated as valuable
customer. Furthermore a customer is defined by several attributes like name, address, account number, etc. The run‐time instantiations of business concepts are called cases. A
case must comply with the business rules assigned to the business concept of which the case is an instantiation. When a case violates a certain business rule (which the case should comply with), there is work to be done. This can be work for a business user or work that can be done in an automated way by the information system. In order to determine whether a case complies with or violates a certain business rule, the rule is formalized into expressions. These expressions relate to the attributes corresponding to the business concept to which the rule is assigned.
LIST OF FIGURES
List of tables
Table 1: Procedural versus declarative process modeling (adapted from Goedertier and
1 INTRODUCTION
This research is about designing business processes and in particular designing IT‐systems that support business processes. For process designers it is important to specify processes in an unambiguous way in order to guide workers to do the ‘right thing’. Thereby, it must be clear what the ‘right thing’ is in terms of work processes (i.e. the results of business processes must be clearly specified). An unambiguous specification of business processes is even more important when designing IT‐support systems. That is because when process designers are not capable to specify exactly what results a process should deliver, IT‐ engineers will not be able to meet the requirements as meant by the business.
Nowadays, many IT‐support systems do not meet their business requirements or are not capable of adapting to changes in the business requirements. For example, the Dutch police department is burdened with an IT‐system which does not fit the requirements to support their operations2. This causes problems regarding the agility and efficiency of an organization when their primary business processes mainly depend on (or consist of) IT‐support systems. A business rule approach towards an organization’s business process management offers a solution to this problem of inflexibility. Business rule approaches entail a relatively new way of thinking about business process management, which will be explained later on. In order to design business processes according to a business rule approach (i.e. designing rule‐based processes), a conceptual understanding is needed about the idea behind rule‐based processes. This research provides a framework which elaborates on the main principles of rule‐based process design, thereby allowing for such a conceptual understanding. These different elements, as described in the paragraphs above, will be introduced in more detail in the following sections. 1.1.1 Business processes and IT‐support systems The term business process, as used within this research, is defined by Davenport (1993) as “a structured, measured set of activities designed to produce a specific output for a particular customer or market”. This definition is similar to Pall’s (1987): “The logical organization of people, materials, energy, equipment, and procedures into work activities designed to produce a specified end result (work product).” Both definitions focus on processes in producing a specific output or end result. This is an important notion of business processes, because it is the output that provides a business process its raison d'être. The better the specification of the output, the more capable workers or systems are to produce the desired result. However, instead of focusing on specifying the desired result, organizations often tend to unduly specify how the result should be produced.
“The fact is that all organizations operate in accordance with a set of underlying principles – that’s what ‘organization’ means. Among other things, these principles define the ‘business logic’ that governs the way in which the business conducts itself.” (Morgan, 2002:3). The
2
term business logic covers all knowledge within an organization concerning processes, decision making, guidelines, strategy, procedures, etc.
Nowadays, almost every organization uses information technology (IT) to capture part of the business logic to support their business processes in an attempt to conduct business in a more efficient way. However, businesses often end up with slow, cumbersome information systems. “A problem of today’s standard Business Process (BP) automation systems is that they are too rigid to cope with changing business demands, especially for long running BPs.” (Graml et al., 2008). Seen from a business perspective, this is a problem, because it reduces the ability of a company to timely adapt their business to changes in the business environment. “When the rate of change increases to the point that the time required to assimilate change exceeds the time in which the change must be manifest, the enterprise is going to find itself in deep yogurt.” (Zachman, 1994). Furthermore, often there is a discrepancy between functionality required by the business compared to what is delivered by IT‐systems. This is illustrated by a well‐known comic strip in the field of software development, which is shown in Figure 1.
Figure 1: Tire swing cartoon
1.1.2 Trade‐off between flexibility and support when designing IT‐support systems
time, flexibility to adapt to changing business conditions. Here, flexibility is defined as the ability to defer (decide to decide later), change (decide to change) and deviate (decide to ignore) from the process model. When business processes are well structured and do not require much flexibility, classical workflow management systems are able to provide good process support. However, when more flexibility is needed, the possibility of PAIS‐systems to provide support is decreasing significant. This paradox is illustrated by Figure 2. fl exi bil ity Figure 2: Process management systems offer support or flexibility, but not both 1.1.3 Business rule approach as a solution for the problem of inflexible IT‐support systems
2 RESEARCH DESIGN
This chapter describes how this research is performed. First, the problem as described in the previous chapter is translated into a research objective. Secondly, given the research objective, the contribution of this research is determined and placed within its context. Thirdly, the research model is presented, which describes the steps that have been taken in order to realize the contribution of this research. The research model includes the research questions. Fourthly, research strategies are described, which are used to acquire the knowledge needed to answer the research questions. Fifthly, it is explained why this research is initiated by TNO ICT. Finally, a chapter outline is provided.
The first three sections together are called the conceptual research plan, whereas the latter sections describe the technical research plan (Verschuren and Doorewaard, 2003).
2.1 Research objective
As discussed in the previous chapter, businesses are in need of more flexible business process management systems in order to increase business agility. At the same time, IT‐ systems need to provide support and prevent workers to act outside the boundaries of their responsibilities. The business rule approach towards process management systems (i.e. rule‐ based processes) is suggested as possible solution. Therefore, the following research objective is stated:
‘Increasing business agility while maintaining business rule compliance, by means of rule‐ based processes.’
Research objective
2.2 Contribution of this research
Figure 3 provides a graphical representation of the problem context. The upper three elements (i.e. rule‐based processes Æ flexible business process management Æ business agility) represent the research objective. Several aspects can be identified as essential for enabling rule‐based processes, including business rule management, execution systems and rule‐based process design. The choice is made to focus on the latter one, because TNO ICT gives priority to this aspect and the other aspects can not be investigated within the researcher’s available time.
2.2.1 What this research is about
designing rule‐based processes. The scope of the research is indicated by the dotted line in Figure 3.
Figure 3: Problem context 2.2.2 What this research is not about
thoughts about this topic are expressed in sections 6.4 and 7.3 as starting point for further research.
2.3 Research model
2.3.2 Sub questions The following sub questions (Q1‐4) are derived from the research model and central research question. These sub questions structure the research project by determining the knowledge which is needed to answer the central research question. Q1 What is a business rule approach and how can it be used for business process management? Q2 What does the rule‐based process model look like? ‐ What terminology is used for process design? ‐ Which rule‐based process models are already developed? Are they useful? ‐ What are the key elements, relations and rules that define the process model? Q3 What does the business concept model look like? ‐ How does data relate to rule‐based process management? ‐ How does rule‐based process management fit with UML?
‐ What are the key elements, relations and rules that define the business concept model?
Q4 What lessons can be learned from implementing a rule‐based process management system?
2.4 Research strategies
This research mainly consists of a desk research about the business rule approach, process design and process management. Literature is acquired by using search engines, reference lists and library catalogues. This is used to provide an answer to research questions 1.
The development of the rule‐based process model is done during weekly discussion sessions at TNO. The acquired knowledge for answering research question 1 is used as input for discussion. Besides the development of the process model, these meetings are used to monitor the progress of this research. The results of these meetings are documented in this report. Thereby providing the required rule‐based process model and providing an answer to research question 2. The same approach is used for answering research question 3 about the business concept model.
Finally, a proof‐of‐concept prototype of a rule‐based process management system has been built in order to show the efficacy of the models. Lessons learned from the prototype are used to improve the design. The prototype also serves as a demonstrator, which TNO can use to show the concept of rule‐based process design. TNO perceives a demonstrator as an effective way to present new ideas, as a demonstrator makes them tangible. The development of the prototype has been done in parallel with the main part of this research, because the models provided input for the prototype and vice versa.
2.5 Role of TNO ICT
improving innovative capabilities of businesses and governmental organizations3. Given the potential benefits of the business rule based approach for bridging the gap between business and IT, and the capabilities of TNO in targeted innovation for competitive advantage, the research about rule‐based process design suits the organization TNO.
This research is initialized by the department of security of TNO ICT, in particular by Rieks Joosten, who also acts as supervisor. The relevance of this research in the field of security is given by the opportunities which rule‐based processes provide in terms of compliance with business policy. Business policy is about rules, regulations and objectives of an organization, which also includes all security aspects. Security in itself is not important, but it depends on the context of the subject, in this case the context of a business environment. Therefore, security should be viewed as a control aspect from a business perspective. Since business rules provide control in a business system and every aspect of control can be addressed by rules, this topic is also interesting when viewed from a security perspective. Furthermore, security is often described in terms of confidentiality, integrity and availability (CIA). Requirements concerning all three can be expressed by business rules. For confidentiality and availability, rule‐based process management provides no more than flexibility. For integrity requirements however, rule‐based process management means a whole new view at accountability of business processes. Since business rules are enforced within an information system, every process, outcome or state of the system can be validated according to the explicitly formulated business rules. This provides new opportunities in the field of security.
Furthermore, Rieks Joosten is involved with the development of Ampersand, a rule‐based process management mechanism. Rule‐based process management has a high potential for bringing business process management closer to the business since business rules can be communicated much easier than current practice process models. Ampersand is “inspired by the belief that compliance with business rules should come automatically, once agreement about rules has been established. Design artifacts such as data models and service specifications ought to be derived from business rules, rather than drawn up by designers.” (Joosten et al., 2010). If only for one bit, this research aims to contribute to this ambition.
2.6 Chapter outline
Figure 5 provides an overview of the research steps and results. On the right‐hand side the associated chapter numbers are given. Together the Rule‐based Process model and the Business Concept model constitute the framework for rule‐based process design, which is the result of the whole research project.
Figure 5: Research steps and results
3 BUSINESS RULE APPROACH
This chapter answers the first sub question: ‘What is a business rule approach and how can it be used for business process management?’ It first introduces business process management and makes a distinction between procedural‐ and declarative process modeling. This is followed by a description of the business rule approach and how business rules relate to business processes. Then the use of information technology for supporting rule based processes is discussed and smart systems are introduced. Furthermore attention is given to languages in which rules can be expressed. Throughout the chapter an ordering process is used as running example to clarify the different concepts. This chapter concludes by providing an answer to the research question.
3.1 Business process management
Business process management emerges from the observation that activities are performed within an organization to provide the market with products or services (Weske, 2007). Since business processes are defined as the set of structured activities to produce this output (Davenport, 1993), business processes management is the key instrument in organizing these activities. Performing activities requires company’s resources, including human resources, information systems and other assets. “A company can reach its business goals in an efficient and effective manner only if people and other enterprise resources, such as information systems, play together well.” (Weske, 2007:4). Business process management therefore plays an important role for this effective collaboration.
“Business process management includes concepts, methods and techniques to support the design, administration, configuration, enactment, and analysis of business processes.” (Weske, 2007:5). Business process management uses explicit representations of business processes, where activities and execution constraints are defined. The explicit representations enable the possibility to analyze and improve or adjust the business processes. This section discusses two different modeling techniques to represent business processes, starting with a procedural business process model.
3.1.1 Procedural business process model
business process is terminated. For every activity a procedure is defined, which specifies how the activity must be performed. Furthermore, during the process three checks are performed which lead to a certain decision concerning the flow of the process.
Figure 6: Procedural business process model of an ordering process
More flexible workflow management systems allow users to deviate from the prescribed execution path (Pesic and van der Aalst, 2006). Case‐handling‐ and adaptive workflow management systems are a response to the demand for more dynamic business process management techniques. In case‐handling workflow management systems, users are able to adjust to some extent the process model for ‘whole cases’. For example, a certain incoming order in the example of Figure 6 can follow an adapted execution path. Adaptive workflow management systems enable users to change the execution paths for the process in general. Although these flexible systems allow for deviations of the prescribed process model, they remain imperative process models. Pesic and van der Aalst (2006) speak of imperative models written in imperative languages, where Goedertier and Vanthienen (2007) speak of procedural models written in procedural languages. This research will use the latter terminology.
Initially, procedural models are a clear way of structuring processes. However, it becomes very complex over time as procedures or decision logic change, new (sub) activities emerge or in general: the business logic alters, because of the changing business conditions. In practice, this results in large, complex process descriptions, which cause operational inefficiency, miscommunication, and inaccessible rules. Furthermore, the created complexity makes is harder to adjust the business processes when needed. This is a disadvantage due to the increased pace of current business practice. When organizations are not able to timely adapt their process models, employees are confronted with obsolete business processes. “The rigid nature of today’s systems results from the way they model and enact the business process.” (Pesic and van der Aalst, 2006:169).
3.1.2 Declarative business process model
is called a declarative process model. Unlike imperative languages, declarative process models enable the possibility to specify what should be done without specifying when and how it should be done (Pesic and van der Aalst, 2006). How a business process is performed is left to the user. The user is guided by the process model to produce the required output given the constraints. Goedertier and Vanthienen (2007) speak of declarative process model, when “it explicitly takes into account the business concerns that govern business processes and leaves as much freedom as is permissible at execution time for determining a valid and suitable execution scenario.” These business concerns include regulations, policies, costs and benefits, time, information prerequisites, and technical and common‐sense constraints. Whereas the specifications of the business process about these concerns are implicitly modeled in procedural business process models, they are explicitly stated in declarative models by specifying constraints. The execution scenario(s) of declarative models can be derived from the constraints and is therefore implicit, whereas it is explicitly stated in procedural models. Specifying the required output of business processes is a key aspect for declarative modeling. Declarative modeling is goal‐driven, whereas procedural modeling is state‐driven. Another difference between the two types of modeling is the modality, which deals with the relationship between reality and the model. Modality concerns the way in which a model describes business processes and how users are encouraged to start these processes. “Procedural process models inherently have the necessity modality (what must) attached, whereas declarative process models allow for other modalities like intention (what
ought), possibility (what can) and certainty (what is).” (Goedertier and Vanthienen,
2007:605). Declarative process models offer flexibility when business processes are being executed. The declarative modalities “… allow to distinguish between what is strictly required (hard constraint) and what is merely desirable (soft constraint) behaviour…” (Goedertier and Vanthienen, 2007:605). The differences between procedural‐ and declarative process modeling are summarized in Table 1.
Procedural modeling Declarative modeling
Rule enforcement procedural (what, when,
how)
declarative (what)
Business concerns implicit explicit
Execution scenario explicit implicit
Execution mechanism state‐driven goal‐driven
Modality what must what must, ought, can
Table 1: Procedural versus declarative process modeling (adapted from Goedertier and Vanthienen, 2007)
Constraints and required output of declarative business processes can be formulated in terms of business rules. The next section discusses the business rule approach.
Figure 7: Declarative business process model of an ordering process
3.2 Business rule approach
As stated before, the business rule approach can be seen as a paradigm shift in thinking about business process management compared to conventional practices. It advocates the separation of business logic and business processes. In order to explain the business rule approach, Ross (2003) uses an analogy to the human body, which will be briefly discussed in this section. Ross (2003) roughly distinguishes three basic components of the human body, which can be seen separately yet are highly interconnected. These components are: 1) the skeleton, which provides structure to the body by the bones, 2) muscles, which are connected to the bones and provide power, and 3) the nervous system, which connects to the muscles and provides power to the human to control the body. The different roles of the components – provide structure, power and control – can also be applied to business systems. The different components will be discussed in the following sections.
3.2.1 Structure: skeleton and business vocabulary
which should be unambiguous given a particular context of usage.” (Ross, 2003:54).
Customer, Order, Delivery and Invoice are examples of terms, which represent a certain
concept in a particular business context. The relationships between terms are called fact
types. Fact types are given by declarative sentences, which relate two or more terms. For
example: ‘Customer places order’, ‘delivery belongs to order’ and ‘invoice is paid by customer’ are fact types of the ordering process. Together, terms and fact types determine the business vocabulary.
It is worth here to mention the difference between types and instances. The business vocabulary represents types of things rather than instances of those things. For example: a business might have thousands of customers, in the business vocabulary they are represented by the single term Customer. Likewise, a fact type represents a relationship between terms, whereas facts represent the instances of those relationships. For example: fact ‘Johnson places order#6442’ is of fact type ‘Customer places order’. Only terms and fact types are allowed in the business vocabulary. Rules, however, can refer to instances of terms and facts.
3.2.2 Control: nervous system and business rules
The Business Rules Group defines a business rule from a business perspective and an IT perspective (Chapin et al., 2007). The business definition is already mentioned in the introduction of this chapter and reads ‘a directive, intended to govern, guide or influence business behaviour’. From an IT perspective a business rule is defined as ‘an atomic piece of reusable business logic, that is specified declaratively’. Business rules provide control in a business system and every aspect of control can be addressed by rules. In other words, any rule that is used to govern the business is called a business rule. “Essentially, a business rule can be any verifiable agreement among stakeholders.” (Joosten, 2008:24). Textbox 1 shows different examples of rules which capture business logic of the ordering process. The categorization of rules is explained later on.
Textbox 1: Example business rules of an ordering process
An important aspect of business rules is that they relate directly to terms and fact types. Business rules build directly on the business vocabulary and provide constraints to the terms and fact types within. Whereas terms and fact types of the ordering process probably never alter, the business rules on the other hand are more likely to change at a certain point in time. For example, a business rule like “an invoice is sent within 5 days after delivery” or “payment is done by customer within 14 days after invoice is sent” is subject to business policy at a certain time, as the business can decide to extend the payment period for invoices. This is why the business rule approach advocates so called ‘rule independence’. Rule independence means separating business rules from business vocabulary and processes. It enables direct management of the rules, which brings the implementation of IT closer to the business side.
According to Ross (2003), rules come in three basic varieties based on the type of control they provide: rejectors, producers, and projectors. These categories will be discussed briefly4, because it gives an impression of the widespread applications of busines
#
s rules.
2. A producer rule is any rule that simply computes or derives a value based on some mathematical function(s). This can be an arithmetic operation (such as, sum, multiply and average) or a logical operation (such as, AND, OR, NOT and EQUAL TO). For example, a producer rule could specify that the VAT equals 19% of the selling price. Producers automate computation. Therefore, no programming is required to implement them. Their overall purpose is to boost end‐user and programming productivity.
3. A projector rule is the exact opposite of a rejector rule. Whether a rejector tends to reject an event, a projector rule always accepts them and automatically takes some other action. The projector type of rule will be explained in more detail in section 3.3 when discussing rule‐ based process management.
Other classifications are presented by Schacher (2006), Goedertier and Vanthienen (2007), Wagner (2005), Iacob (2009), Weiden, Hermans et al. (2008) and others. These will not be discussed, because within this research it is not important to have a classification of business rules. A classification of business rules is valuable to recognize all kinds of rules within a business context. Furthermore, it allows for a more complete list of business rules, since a business rule classification provides all possible structures of rules. These are topics of business rule management, which is left out of the scope of this research.
3.2.3 Power: muscles and processes
Like in the human body, a business system must have power to produce motion (i.e. output). In the business rule approach it is the processes that carry this functionality. Business processes are the way businesses make money, because a process transforms input into desired output. As discussed in section 3.1 traditional approaches often result in very complex processes, which are hard to adjust to changing business conditions. Due to the principle of rule independence, rules are separated from the business vocabulary and business processes. Like the business vocabulary, processes itself are less likely to change than the business rules governing these processes. Looking at the implementation of the processes in traditional information systems, much of the programming code is devoted to editing, validations, derivations, and calculations. Those are the things for which rules are most suitable. Therefore, by removing the business rules from the processes, rule independence results in very thin processes, which are easier to change (Ross, 2003).
3.2.4 Basic ideas of the business rule paradigm
Ross (2003) formulates the basic ideas of the business rule paradigm as follows:
1. All three components – structure (terms and fact types), rules, and processes – are essential. 2. The three components are obviously interrelated.
3. Each of the components is specialized for a particular role or responsibility.
4. In many ways rules are the most important component since they provide control for the other two.
Section 3.1 explained that business processes can be modeled in a declarative way by specifying the required output and constraints. Section 3.2 introduced the business rule approach as a way to formulate a declarative business process model. The next section will explain how activities – i.e. work processes – are initiated in a declarative business process with the use of information technology.
3.3 Rulebased process management
Next to the grouping of business processes based on the type of modeling – procedural‐ versus declarative process modeling – a process can be classified based on their control mechanism. Joosten et al. (2007) mention two known mechanisms: 1) process control based on activities, of which workflow management is an example; and 2) process control based on cases, also known as case management. They introduce Ampersand – a control mechanism based on rules – which adds rule‐based control mechanisms as a third type of process control mechanism. Furthermore, Joosten et al. (2007) link the different control mechanisms to Mintzberg’s typology of organizational structures, where they state that certain control mechanisms are more appropriate for particular types of organizations. This will be explained in more detail in the following section, because it explains the appropriateness of the business rule approach for dynamic organizational structures. The subsequent sections explain the rule‐based process control mechanism and discuss the benefits of it.
3.3.1 Mintzberg’s organizational structures
Mintzberg (1980) identifies five different configurations of structure, based on the natural grouping of elements of structure. These elements are: the coordinating mechanisms, the design parameters – which are the means organizations have to design structures – and the contingency factors that influence the choice of design parameters. The grouping of elements resulted in the following five configurations:
1. Simple Structure. Top management of an organization exerts a pull for
centralization in order to retain control over decision making.
2. Machine Bureaucracy. The organization is highly standardized. The technostructure
(e.g., accountants, work schedulers, long‐range planners)
exerts a pull for standardization of work processes, because
the design of the standards is its right to exist.
3. Professional Bureaucracy. The operating core of the organization works relatively
autonomously. They exert a pull for professionalism.
4. Divisionalized Form. The organization is split into market‐based units which can
5. Adhocracy. The organization is structured into work constellations to which power is decentralized selectively and which are free
to coordinate within and between themselves by mutual
adjustment.
Activity‐based process management (A‐BPM) is only appropriate for the machine
bureaucracy, because there is no possibility to deviate from the prescribed workflow
standard, which is exactly what the organizational configuration pursues. Case‐based process management (C‐BPM) is more flexible – since business rules are used within processes – and is therefore appropriate for both the machine‐ and professional bureaucracy. Rule‐based process management (R‐BPM) is by far most flexible, because the processes are driven by the business rules. Rule‐based process management is therefore valuable for Mintzberg’s
adhocracy, because it enables flexibility for a decentralized organizational structure, while
providing the same amount of support. An overview is provided by Table 2.
A‐BPM C‐BPM R‐BPM
Mintzbergs typology
Machine bureaucracy Professional bureaucracy Adhocracy
Business rules Next to process Used in process Equals process
Table 2: Process control mechanisms (adapted from Joosten et al. 2007) 3.3.2 How it works
“The principle of rule‐based process management is that any violation of a business rule may be used to trigger actions.” (Joosten and Joosten, 2007:3). This means that every time a business event occurs, a rule engine checks all related business rules for possible violations. When a violation is detected by the rule engine, action should be taken to resolve this violation. Violations of rules that are maintained by an information system lead to automated action. Other violations lead to signals to the business users, which indicate that action should be taken to resolve these violations. This corresponds to the projector type of business rules as explained in section 3.2.2. More specifically rules that trigger other processes to execute or other rules to fire, are called executive rules, which is a subcategory of the projector rule5.
The following example scenario of the ordering process, determined by the business rules from Textbox 1 in section 3.2, illustrates rule‐based process management.
1. A customer places an order. The rule engine detects an order which is not accepted or rejected. This is a violation of the first business rule. A signal is sent to the business user to either accept or reject the order.
2. The user accepts the order. The violation of rule 1 is resolved. However, now rule 3 is violated, because there is an accepted order which is not delivered. A signal is sent to the user to deliver the order.
3. The order is delivered, which resolved the violation of rule 3. This resulted in the violation of rule 6, which signals the user to send an invoice.
4. The invoice is sent. The user receives a signal that there is an outstanding invoice, because rule 8 is violated. A reminder could be sent when this takes to long. Additional business rules should determine when to do this.
5. The customer has paid the invoice. No rules are violated anymore. The ordering process is terminated.
the violation of the rule ‘every order must be either accepted or rejected’ logically leads to an activity to accept or reject the order.
3.4 Formalizing business rules
To be able to deal with business rules in an automated way, business rules need to be formalized from natural language to a language which can be evaluated by computers. Several solutions are available with different degrees of formalization. This section describes three languages in ascending order of degree of formalization. These are BRS RuleSpeak, SBVR and ADL. The reason why these languages are discussed is because of their connection with earlier discussed theories and related work.
3.4.1 BRS RuleSpeak
RuleSpeak is a language for business rules, developed by the Business Rule Solutions group. Ronald G. Ross is co‐founder of the BRS group and his ideas about business rules are used within this research. RuleSpeak provides a structure for expressing business rules in English. It consists of an amount of rule sentence templates which are patterns of basic rule structures that can be used to express rules in a consistent and organized manner (Ross, 2003). Examples of rules written in RuleSpeak are: ‘Orders on credit over $1,000 must not be accepted without a credit check.’ ‘An order may be accepted only if all of the following are true: 1) It includes at least one item. 2) It indicates the customer who is placing it.’ It is worthwhile to note that business rules are not described by if…then constructions. For example, ‘if customer exists, then customer must have an address’ is expressed in RuleSpeak as ‘customer must have an address’. RuleSpeak does not represent a formal language, which can be used for implementing rules at the system level. Rather, it aims toward improving communication between practitioners at business level.
3.4.2 Semantics of Business Vocabulary and Rules (SBVR)
Since 2008, there is an OMG6 standard language for declarative description of a business domain, called SBVR (Semantics of Business Vocabulary and Rules) 7. SBVR is the OMG’s implementation of the business rule approach. Like RuleSpeak, SBVR is a natural language modeling vocabulary. However, the SBVR specification provides a structured, English vocabulary for describing business vocabularies and verbalizing business rules. The vocabulary of business concepts and the set of business rules together constitute a so called conceptual schema, which in turn can be transformed into formalized logic statements. In this way, SBVR provides a possibility for the business to transform natural language business rules into formalized statements which can be used by IT‐systems. However, SBVR is a very extensive and complicated standard, which is not easily understandable for business people who do not deal with process design on a day‐to‐day basis. Furthermore, SBVR requires a precise way of formulating business rules in structured English, because small grammatical variants can have large implications for the outcome of the specification process.
6
Object Management Group
3.4.3 A Description Language (ADL) ADL stands for A Description Language and can be used to define a repository in which rules can be stored within their contexts (Joosten et al., 2010). It uses relation algebra to express business rules. Business rules are seen as formal representations of business requirements. Therefore, ADL is suitable for use in the Ampersand approach, which is discussed earlier in section 3.3, where processes are management by the rules that define the business. ADL – and relation algebra in general – is powerful for expressing rules in an unambiguous way. No room is left to speculate about how to evaluate the rules. Therefore, ADL is suitable for expressing business rules when they need to be evaluated automatically. Key concepts within ADL are concepts, relations, rules, valuations and patterns. The complete table of words used in ADL with their meaning is provided in Appendix 2.
The graphical modeling technique that comes with ADL has been very valuable for the development of the models within this research and is used to support the discussion of the models in the following chapters. An ADL model consists of concepts, relations and rules. The graphical representation of an ADL model only illustrates concepts and relations; however, the rules are essential for the right interpretation of the model. Concepts are represented by dots, relations by lines and arrows are used to indicate the direction of the relations. Furthermore, multiplicities of the relations between concepts are visualized. When the multiplicity is not provided by a linkage, the shape of the arrow implicitly states the multiplicity as shown in Figure 10. This is to prevent an overkill of multiplicity constraints within the graphical models. The graphical modeling technique provides structured support for fundamental discussions about process design. 0..n 1 Figure 10: Implicit multiplicity constraints 3.4.4 Formalizing business rules Although RuleSpeak does not provide a method to transform business rules into formalized statements, it is more likely business people will adopt RuleSpeak than SBVR. This is sufficiently, because process designers already benefit when business people think of rules in a declarative way and because formalizing business rules is a very specialized skill. It is up to the specialist to transform the business rule determined by the business people into formalized statements in a language like ADL. When, in the future, processes are built entirely upon business rules, the role of a process designer will probably shift from designing processes to formalizing and managing business rules.
3.5 Summary
1. A business rule approach towards business process management explicitly formalizes business logic in the form of business rules. These rules originate directly from the business itself; thereby enabling IT‐support systems to meet business requirements accurately.
2. Business rules represent business logic, not business processes. The motives to change business processes are different from the motives to change underlying business logic. For example: changing regulations or new business strategies can affect business rules without changing core business processes. On the other hand, new processes can be designed according to the same business rules.
4 RULE‐BASED PROCESS MODEL
This chapter is about the second research question: ‘What does the rule‐based process model look like?’ It first discusses the background of process design and the terminology used. This is followed by an analysis of other rule‐based process models, which determines the point of view for looking at process design. Then the concepts and rules that define the rule‐based process are elaborated with explicit attention for the underlying conceptual reasoning. As in the previous chapter, the ordering process is used as running example to clarify the matter. This chapter concludes by recapitulating the rule‐based process model and thereby answers the second research question.
4.1 Process design
Davenport (1993:7) states that “Taking a process approach implies adopting the customer’s point of view. Processes are the structure by which an organization does what is necessary to produce value for its customers”. According to Davenport, there is an emphasis on the result of processes and its value for customers. This is in line with the earlier developed Value Chain Model by Porter (1985). Joosten (2002) also refers to the value chain as foundation of process thinking. The following section elaborates on the topic of value chain thinking. In the subsequent sections attention is paid to the Process Architecture Model of Joosten (2002) and key terminology for process design. Furthermore the distinction between define‐time and run‐time state of a system is made, because this is needed for a clear discussion about process design. 4.1.1 Value chain thinking With the Value Chain Model, Porter (1985) laid the groundwork for current comprehensive business process management. The value chain includes all organization’s activities which are needed to design, produce, market, deliver and support a product or service (Harmon, 2007). The overall organizational business process delivers added value for a customer, which is illustrated in Figure 11. However, not only the overall business process delivers value, every internal sub process also produces added value. The value chain delivers more added value than the sum of all activities.The importance of Porter’s Value Chain Model is that every primary‐ and support activity should be included in a single value chain. Business processes cross functional boundaries within an organization. The focus of process design should not be on divisional efficiency, but on value chain optimization. When looking outside the organization, the organization’s value chain can be seen as part of a broader value chain which links organizations from raw material to consumer end‐product. Nowadays, companies are also looking at inter‐ organizational value chain optimization.
Figure 11: Value Chain (Porter, 1985) 4.1.2 Process Architecture Model (PAM)
The Process Architecture Model (PAM)8 is a reference model for process designers. It positions key process design terminology in order to discuss process design related issues. The elements are: value chain, process, procedure, activity, action and event. The value chain has been discussed already; the other elements are explained below. The graphical representation of the PAM is shown in Figure 12. PAM is discussed here, because it explains how current practice process architectures are build up in different levels. These levels will be used to position the rule‐based process model. Process: processes are characterized by the result/added value they deliver within the value chain. It is important to notice that the result is important in this context, not how the result is achieved. The process level is about the what discussion. Procedure: a procedure prescribes every activity that holds for cases of a certain type. Within this research, case type is called business concept. An example of a procedure is customer
order handling. This procedure prescribes the sequence of activities that need to be executed
for every customer order, where customer order is the business concept. A procedure in PAM can be viewed as a procedural process model, not as a declarative process model. The procedure is about the how discussion.
Activity: the activity level is the level where the actual work is done. Activities consist of actions and decisions that can be done without work transfer to, or communication with, other actors. For example the activity send invoice consists of a couple of actions that need to be performed by an employee (or, when automated, by a system). In order to send an
invoice, it should be composed, printed and mailed. A difference between an activity and a procedure is that for activities the sequence of actions is not prescribed.
Action: actions are the smallest autonomous units of work, for example: print document. When print document is divided into smaller pieces of work – select printer, configure
settings, press print – this is not an action, but an activity. Event: an event is something that happens at a certain moment. An action triggers events to be executed. Figure 12: Terminology PAM (adapted from Joosten, 2002:28) Class type of Object 4.1.3 Modeling‐time versus run‐time In order to not ending up in confusing modeling discussions, a distinction is made between modeling‐time and run‐time models.
Modeling‐time refers to something that occurs during a modeling activity of the software development process. Also referred to as define‐time; the phase where classes are defined. For example, a model of an ordering process defines classes like order, customer and delivery. The same counts for processes. Processes are designed in define‐time, whereas the execution of a process is performed in run‐time.
Run‐time refers to the period of time during which a system/model/computer program executes. This is when classes are instantiated to objects. For example, order#42951 is an instance of the class order and Johnson is an object of the type customer.
4.2 Prior research
This section summarizes earlier work in the field of rule‐based process modeling. Shao (2010) performed a study at TNO which resulted in a reference architecture for Claims‐Based Working. The relevant results of his study will be presented in the following section. Furthermore, two other frameworks are discussed and assessed for use within the rule‐based process model. This provides the starting point for developing the rule‐based process model. 4.2.1 Reference architecture Claims‐Based Working.
Shao (2010) discussed a couple of business activity access control mechanisms. Two of these perspectives are explained within this section. The first perspective is the control‐flow mechanism, which is illustrated in Figure 14. Access control criteria are formulated in terms of sequences. Activity A is carried out first, then activity B and finally activity C is carried out. The Access control mechanism is located at the start of an activity. This perspective is a true procedural way of managing business processes.
Activity A
Activity B
Activity C
Figure 14: Control‐flow perspective
Another way of looking at business activity access control is the data perspective, which is illustrated in Figure 15. The control mechanism is still at the start of an activity; however, the criteria are not based on the completion of a preceding activity, but on the data it requires. This is a declarative way of managing business activities. It is not prescribed how to produce the required data, only what is required in order to start the activity. For example, activity A produces the data which is needed as input for activity B. Within the control‐flow mechanism only activity A can be performed to deliver the required data. The data perspective on the other hand enables a more flexible approach to deliver the required data, since it is not specified which activity should be performed. Therefore it is possible that activity A’ will produce the data instead of activity A.
4.2.2 Declare
Declare9 is a constraint‐based workflow management system that provides for multiple declarative languages, such as DecSerFlow and ConDec (Van der Aalst et al., 2009). Instead of explicitly defining the procedural order of activities, Declare models implicitly determine the possible ordering of activities by setting constraints. Any order that does not violate constraints is allowed. Although Declare is called a declarative process modeling technique,
