brm - an introduction - pna€¦ · agility,! i.e.! having! the! ability! to move! and change ......
TRANSCRIPT
Business Rules Management – an introduction
From: CogNIAM Finance
Authors: Inge Lemmens, John Bulles, Popke Rein Munniksma
Date: October 14th, 2013
Version: 1.0
2
Executive summary Agility, i.e. having the ability to move and change direction quickly and effectively while keeping control, is aspired by many organisations in their strive towards fulfilling compliance requirements and maintaining or achieving a competitive position in the market. In this paper, we introduce business rules management as a means to aid organisations to achieve their ambition of agility.
Business rules management (BRM) is the discipline that aims at explicitly specifying business rules and managing them independently of their different usages (implementation). That is, BRM is about making the business rules explicit in such a manner that they are understandable by the business (and hence can be managed by the business) and are also formal enough to automate them in a consistent manner (if required). BRM gives an organisation insight in the rules that determines its behaviour. Having insight in these rules leads to a consistent and transparent application of them, which in turn increases customer satisfaction. Moreover, the increased awareness about and understanding of business rules that apply also increases the effectiveness of the organisation since interpretation errors and misunderstandings are prevented as much as possible.
Classification of business rules
Business rules manifest themselves everywhere: on the data to ensure data quality, in the processes to control the flow, in services that encapsulate business logic. In this paper, we present a classification of business rules into constraints that govern the data, process rules that guide the processes and derivation rules that derive new information by calculation or decisions. This categorisation allows for optimal management of rules in close cooperation with those disciplines on which the rules have an impact. As a matter of fact, business rules should not be studied in isolation of other aspects of the business. In particular, business rule management is highly intertwined with data management and process management and forms together with these disciplines the basis for a solid service-‐oriented architecture that provides the flexibility and rapid reaction to change required.
Central coordination
It is not necessary to create one central repository for everyone to use. Of essence is that rules are defined once, in close connection to their usage, potentially distributed throughout the organisation but centrally coordinated such that together they form one single point of truth. That is, rules can be managed in different environments, but the complete resulting set of rules should be coordinated in such a way that all pieces together form a consistent whole.
Governance in place
For any business rules management initiative to become successful, the governance structure surrounding business rules management needs to be put in place. That is, organisational structures, supporting communication and processes should be established to ensure consistent management of business rules.
3
Contents 1 Introduction .......................................................................................................................... 5
1.1 Overview of the paper .................................................................................................. 5
2 Why business rules management? ........................................................................................ 7
2.1 Reducing complexity .................................................................................................... 7
2.2 Increased predictability and maintainability ................................................................. 8
2.3 Agility ........................................................................................................................... 8
3 Definitions for business rule ................................................................................................. 9
3.1 Business rules as a synonym for decision rules? .......................................................... 9
3.2 Business rules as a synonym for production rules? ...................................................... 9
3.3 Business rules as a synonym for data integrity constraints? ....................................... 10
3.4 What are business rules really – a synthesis ............................................................... 10
4 Rule classifications ............................................................................................................. 10
4.1 The “best of breed” classification ............................................................................... 11
4.2 The Business Rules Group classification .................................................................... 13
4.3 The SBVR classification ............................................................................................. 13
4.4 The RuleSpeak classification ...................................................................................... 13
4.5 The CogNIAM classification ...................................................................................... 14
4.6 The Primatek classification ......................................................................................... 14
4.7 The relationship between the proposed classification and the other classifications .... 15
5 Business rules management versus business rules engine .................................................. 19
5.1 Business rule management system (the know) .......................................................... 19
5.2 Business rule engine (the how) ................................................................................... 19
5.3 From rules in a business rules management system to realisation .............................. 20
6 Business rules in relation to other disciplines ..................................................................... 21
6.1 Business rules management and data management .................................................... 21
6.2 Business rules and business process management ...................................................... 21
6.3 Service-oriented architecture in relation to BPM and BRM ....................................... 21
7 What kind of rules are managed in a business rules management system? ........................ 23
7.1 Criteria for identification of the rules to be managed in a BRMS .............................. 23
8 Rule governance ................................................................................................................. 25
9 Conclusions ........................................................................................................................ 26
10 References ...................................................................................................................... 27
4
ANNEX A: Different classifications explained .......................................................................... 28
A.1 The Business Rules Group classification ................................................................... 28
A.2 The SBVR classification ............................................................................................ 29
A.3 The RuleSpeak classification ..................................................................................... 29
A.4 The CogNIAM classification ...................................................................................... 30
A.5 The Primatek classification ......................................................................................... 31
5
1 Introduction
In today’s business environment, the challenges an organisation has to face, have increased in amount and complexity. Not only competition has become tougher, organisations, and in particular financial organisations, have to fulfil an increasing amount of regulations imposed by external organisations, like the “De Nederlandse Bank (DNB)”, the “Autoriteit Financiële Markten” (AFM), and the “European Central Bank (ECB)”.
For an organisation to maintain (or achieve) the competitive edge and to be compliant to ever changing regulation it is required to be able to react in a timely fashion to changes in their immediate environment that affect their business. This can only be achieved if an organisation has a grip on the rules that determine its behaviour; i.e. their business rules.
An organisation that has a grip on its business rules not only becomes more flexible and agile, but the organisation also becomes more consistent throughout its business activities. Having insight in the business rules leads to a consistent and transparent application of these business rules which in turn increases customer satisfaction. Moreover, the increased awareness about and understanding of business rules that apply increases the effectiveness of the organisation since interpretation errors that might occur due to misunderstanding of rules is prevented as much as possible.
Explicitly specifying business rules has a positive effect on the organisation’s dynamic behaviour, its overall agility. Changes to rules do not necessarily impact existing processes implying that these changes can be implemented swiftly in a consistent manner implying flexibility and a timely response to changes. This in particular in those cases that the business rules are maintained in a business rules management systems (BRMS) that forms the source of transformation rules that transform the formally described rules in the BRMs to execution scripts in the different target implementations. Especially in a service-‐oriented architecture, this flexibility of change through implementation of the rules in services is what provides an organisation the flexibility it needs.
As with any “management” discipline, it only becomes successful if the governance structure to support the management initiative is in place. No business rule management project will be successful if the supporting governance processes and people are not in place.
1.1 Overview of the paper
In this paper, we discuss different interpretations of the term “business rules” (section 2) and different classifications that are used throughout literature and in practice. These different classifications are set-‐out against each other in the paper and an alternative, more encompassing classification is provided (section 4).
Business rules management is about making business rules explicit in such a manner that they are understandable by the business and also formal enough to automate them in a consistent manner, if required. In section 5, the difference between a business rule management system and a business rule engine is explained. Of particular interest is that, by explicitly defining and maintaining business rules in a business rule management system that uses a formal yet understandable language, different realisations can be supported through ((semi-‐)automated) transformation rules to the different target implementation platforms. This aspect of business
6
rules management is of essence for achieving the benefits of the approach, which are described in section 2.
Business rules are only one side of the medal and should not be studied or managed in isolation of other aspects of the business. In particular, business rules management is highly intertwined with data management, process management and form together with these disciplines the basis for a solid service-‐oriented architecture that provides the flexibility and rapid reaction to change required. These relations between the different approaches is explained in section 6.
Whenever business rules management is mentioned, it is associated with a single repository in which all business rules are maintained. As we demonstrate in section 7, this “single repository” idea can be relaxed. What is required is a single centre of coordination that ensures that the overall set of rules, managed in different places are consistent and coherent.
Section 8 of this paper introduces a possible governance structure, and in particular the governance processes that should be in place in order for a business rules management initiative to be successful.
7
2 Why business rules management?
Business rules management is one of the latest management disciplines introduced to improve an organisation’s efficiency and effectiveness. The need for business rules management has been recognised by organisations whose business domains are policy intensive and highly relying on decision logic in their daily activities. Business rules are thereby considered as all those rules that influence the organisation’s behaviour.
Business rules management is about identifying the rules of relevance, making them explicit and comprehensible for the stakeholders (in particular, the business) such that they can be managed by those stakeholders such that any technical implementation of the business rules can be performed in correspondence to the meaning and intention of the rule.
2.1 Reducing complexity
Business rules management is often seen as part of business process management, and in particular is often initiated in an organisation as an enabler of process improvement. Among the main reasons for introducing business rules management is reducing process complexity and transaction costs of, and decision errors within, a process task.
Complexity is caused by amongst others increasing diversity inside and outside the organisation. For example, different business models for different business units result in a heterogeneous solution space (each using their own solutions/products/standards). Heterogeneous customer needs, heterogeneous stakeholders (investors, customers, regulators, employees,…) increases the diversity the organisation faces. Another cause of complexity is interdependence without understanding each other due to ambiguity in the information exchange.
Reducing complexity, by providing increased insight in the rules that govern the business, the quality and effectiveness improves and the number of errors caused by faulty interpretations reduces.
2.1.1 Improve quality and effectiveness
Clearly and unambiguously capturing and representing the business rules contained within the business policies in an understandable manner ensures that the business policies are executed in a harmonious way within an organisation. That is, by clear and unambiguously describing the business rules, there is no risk of misunderstanding and thus misuse of the rule. This improves the quality of the organisation’s response to customer’s requests (consistent and transparent advice by application of the rules) as well as the effectiveness of the organisation (by knowing which rules to apply when).
The increased awareness about and understanding of the business rules that apply, reduces maintenance and increases the effectiveness of operations and improves the relationship between employees and customers. Moreover, the customer’s satisfaction is improved through more consistent and reliable interactions between the organisation and the customer; the same question of the same customer shall result in the same outcome, independently of who gave the result at what time.
8
2.1.2 Reducing interpretation errors
Introducing business rules management into an organisation gives the business users a better grip on, and a better understandability of, the business rules. Having a better understanding implies less design/requirement faults which in its turn reduces implementation times and fewer opportunities for interpretation errors.
2.2 Increased predictability and maintainability
Business rules management implies a conceptual single-‐point-‐of-‐truth for the business rules definition. That is, the rules are defined once and can be realised many times. One definition, many realisations based on the same definition increases the predictability of the outcome of the application. One definition, many realisations also improves maintainability, changes are maintained at the definition level and the effect of change can be measured before realisation in any system.
2.3 Agility
“Agility” is one of the primary reasons for organisations to implement a business rule management solution. Agility manifests itself as:
1) Awareness, meaning knowing what the rules are and their applicability 2) Flexibility, by being able to react in a timely manner on expected changes, 3) Adaptability, by being capable to react in a timely manner on unexpected changes, and 4) Productivity, meaning that the right policies and procedures are executed at the right
time.
9
3 Definitions for business rule
For the term business rules, several interpretations exist. This is not surprising, taking into account that a whole set of definitions are available for the term. Existing definitions are:
Not only are there several definitions of the term business rule, the interpretation is often dependent on the way business rule management is supported by means of business rule management systems or business rule engines.
3.1 Business rules as a synonym for decision rules?
“Business rule management systems are software systems used to define, deploy, execute, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organisation or enterprise” [7]. Examination of this description gives the impression that business rules have something to do with decision making. This is exactly how business rules are often positioned within an organisation, namely those rules that define the decision making process in an organisation, in other words the decision rules. Business rules management is therefore often associated with enterprise decision management. Decision management yields managing the decision rules required for decision making, often expressed in terms of decision tables, decision trees, or “if … then …” statements.
Decision rules form a large part of the business rules since decisions govern in many ways the way the organisation organises its knowledge. However, not all business rules can be expressed in terms of decisions. Moreover, the quality of the decisions is only as good as the quality of the data on the basis of which the decision is made.
3.2 Business rules as a synonym for production rules?
A second interpretation of business rules is the interpretation that business rules are “executable” rules, which produce information. This is not surprising, since business rules are often associated with business rule engines, software systems that deploy and execute rules in a runtime production environment. This type of rules has drawn so much attention that different standardisation organisations have “standardised” their interchange (the RIF interchange standard of W3C), or standardised their representation (the PRR standard of OMG). It is the latter that is often used by business rule engines and business rule
“A rule that is under business jurisdiction” [1]
“A statement that defines or constrains some aspect of the business” [2]
“A directive that is intended to influence or guide business behavior” [3]
“An atomic piece of reusable business logic, specified declaratively” [4]
“A single statement that takes data or information that an organization possesses and derives other data from it, or uses it to trigger an action” [5]
“Conditions that govern a business event so that it occurs in such a way that is acceptable to the business” [6]
10
management systems to represent the business rules. Note that decision rules can be considered to be a kind of production rules.
3.3 Business rules as a synonym for data integrity constraints?
A third interpretation of business rules is the interpretation of business rules as being data integrity constraints, which have as purpose to maintain the integrity of the data (i.e., keep the data consistent and correct). This approach claims that a business rule is a business operation reflected in the design of a database.
3.4 What are business rules really – a synthesis
Business rules are all of the above and more. Decision rules, production rules and data integrity constraints are all business rules. And there is even more. Also part of the business rules is the business vocabulary, consisting of the business terms and facts relating these business terms (e.g., the terms “Customer” and “Account” that are related through the fact(type) “Customer owns Account”). These latter two are an important part of the business rules, since business rules build on facts, and facts build on concepts expressed by means of business terms. This statement is exactly the mantra of the business rules group, a non-‐commercial peer group of IT professionals that since 1989 has been working on promoting the business rules approach. It is also this mantra that has formed the basis for the OMG business rules standard called SBVR (Semantics of Business Vocabulary and Business Rules) [1].
Taking all this into account, the proposed definition for business rules is:
With this definition of business rules we include:
1) Those rules that are under business jurisdiction as well as 2) Those rules that are imposed by another entity to which the organisation has to
comply.
Business rules are thus those rules that, when properly managed, aid the organisation in becoming more flexible, more responsive to changes, wishes and needs, as well as those rules that aid the organisation in fulfilling external regulations. That includes constraints, production rules as well as decision rules.
4 Rule classifications
Within literature, different classifications exist for rules and business rules in particular. One of the reasons for introducing rule classifications is to enable the use of templates for stating the rule. That is, according to the class to which the rule belongs, most approaches provide sentence templates that can be used to express the rules belonging to that class. The use of
A business rule is a directive or demand, which is intended to influence or guide business behaviour, in support of a business policy that is formulated either in response to an opportunity or in response to a change of regulation imposed by an external entity.
11
these sentence templates (forming a controlled natural language) ensures consistency of rule specification throughout the organisation.
Another reason for introducing rule classifications is to be able to organise rules such that the set of rules does not become one bucket of rules but can be organised using the classification parameters. This is often very useful when the set of rules increases in size.
In this section, we introduce first the “best of breed” classification for business rules. With “best of breed” we mean that the classification is determined by selecting the most intuitive definition for each type and integrating them instead of using one of the existing classifications. The existing classifications are introduced in the following sections. Details of these classifications can be found in annex A.
4.1 The “best of breed” classification
The best of breed classification is a classification which encompasses different types of rules and which is closely related to the manner rules are generally perceived in an organisation. In the classification, we differentiate between:
1) Constraints, which are statements concerning the enterprise that shall or should always be true. Constraints are either integrity rules or behavioural rules and act on the information used by the organisation.
2) Derivation rules, which are statements that specify how new information is derived from other information.
3) Process rules, which describe the process logic, i.e., the sequence of process steps execution, often referred to as ECA (event, condition, action) rules.
Note that we assume here that the rules (independent of their classification) build on facts that bind terms which are defined. That is, the rules have a solid basis formed by the facts and terms.
4.1.1 Constraints
Constraints are declarative statements that specify to what the results of actions performed must (or should in case of behavioural constraints) adhere. That is, constraints restrain the set of possible outcomes of the actions into valid outcomes.
Constraints are either
1) integrity constraints or 2) behavioural constraints.
An integrity constraint is a constraint that is impossible to violate, while a behavioural constraint is similar to a “strong recommendation”, meaning that the constraint can be violated but it is strongly advised not to do so. Therefore, with a behavioural constraint, the consequence of violating the constraint should be specified.
Examples of integrity constraints are: “each customer shall have at least one account”, “if a customer is registered, then the customer’s account number must be known”.
12
An example of a behavioural constraints is: “each customer should pay its redemption of a loan on time”. The associated consequence may be specified as: “not paying on time shall result in a penalty payment of 2%”.
Based on the above definitions, constraints, and in particular integrity constraints, are responsible for data quality.
4.1.2 Derivation rules
Derivation rules are business rules that use either a mathematical computation, logical reasoning or both to come to new information based on existing information.
When logical reasoning is used (often in the form of if-‐then statements), they are referred to as information-‐generating decision rules. That is, when the outcome of the decision leads to new information. This in contrast to process-‐steering decision rules that specify which action is to be performed next based on the outcome of the decision.
An example of information-‐generating decision rules is: “If the customer has a UCR (credit rate) lower than 4, then no credit can be given”.
When mathematical computation is used, then we use the term “computational rule”. An example is: “The product prize equals the net prize + 21%”.
4.1.3 Process rules
Process rules are those rules that:
1) describe the preconditions and postconditions of processes and activities in the processes, as well as
2) those rules that define who is authorized or responsible for which actions.
Process rules that describe the precondition are those rules that combine the triggering event together with possible conditions that need to be fulfilled before the process (or activity) can be performed.
An example of a precondition would be:
“If a customer requests a savings account (event) and the customer is older than 18 (pre-‐condition)
Then the “create savings account process” can be activated”.
Process rules that describe the postconditions of a process or activity in a process are those rules that describe which conditions need to be fulfilled before the process can be considered to be executed correctly (i.e., with the desired result).
An example of a postcondition could be stated as follows:
The process “new savings account” is executed correctly if and only if
-‐ A new account is created, -‐ The account number is coupled with the customer that requested the account, and -‐ The customer has made a first deposit on the account”.
Note that process monitoring takes place on both postconditions as well as preconditions.
13
Besides pre-‐ and postconditions, we consider also “authorisation rules” for the execution of actions as process rules since they specify who (which role) is authorised to perform the action. Moreover, we add the “responsible rules” as being the rule that specifies who (which role) is responsible for the execution of the action.
The “best of breed” classification proposed in this section has its source in different existing classifications that exist in literature and practice. The most used (well known) classifications are introduced in the following sections.
4.2 The Business Rules Group classification In their final report, the “Business Rules Group” provided the results of the GUIDE Business Rules Project, which had as one of the objectives to define and describe business rules and associated concepts [2]. The main classification provided by the Business Rules Group is the following:
1. Structural assertions, which are statements to assert the existence of a concept of interest or the existence of a relationship between concepts of interest.
2. Action assertions, which are statements that specify constraints on the results of actions, and
3. Derivations, which are rules that use a mathematical computation or a logical induction or deduction to create new facts.
4.3 The SBVR classification The Semantics for Business Vocabulary and Business Rules (SBVR) encompasses more than only the business rules. It also encompasses a “vocabulary part” which focusses on community-‐specific communication. For the purpose of this paper, the focus lies on the classification of rules, and business rules in particular, as supported by SBVR (clause 12 of [1]).
A rule in SBVR is either a business rule or a structural rule. A business rule is a rule under business jurisdiction, meaning that the business owns the rule and has the authority to change the rule. A business rule is based on a policy. A structural rule, being a statement of necessity can also be a business rule (but doesn’t have to be).
4.4 The RuleSpeak classification Ron Ross has introduced in [9] different types of business rules as part of RuleSpeak. RuleSpeak is developed as a natural language to support the business rules approach. In [9], it is specified that RuleSpeak consists of three main components, namely:
1) The structure component which consists of the key concepts and the logical connections between them,
2) The process component which consists of processes that operate on terms and facts, and
3) The rules component which consists of rules that constrain processes to act only in certain ways deemed to be best for the business as a whole.
In RuleSpeak, business rules are defined as: “Directives to influence or guide business behaviour”.
Following RuleSpeak, the following main categories of rules is identified:
14
1) Rejectors, which reject any event that would cause a violation to occur. Rejector-‐type rules address data quality.
2) Producers, which calculate or derive something. 3) Projectors, which produce an event based upon an update event (if this, then that
too). Projectors can be further classified into inference rules or triggers.
4.5 The CogNIAM classification In CogNIAM, business rules are classified to be either:
1. Integrity rules, which have as function to restrict the set of facts and transitions between facts to those that are considered useful.
2. Derivation rules, which are used to calculate new information on the basis of existing information.
3. Exchange rules, which specify how facts are added, removed and/or changed without using a derivation.
4. Event rules, which specify under which circumstances a derivation rule or exchange rule is triggered.
5. Behavioural rules, which specify obligations that ought to be obeyed but may be violated.
4.6 The Primatek classification In [10], a different kind of classification is given, which is not based on the meaning of the rules as expressed above but based on the place where the rule would be implemented. That is, in contrast to the above classifications, the classification given in [10] takes the realisation of the business rule as a categorisation principle. The following classification does not take the meaning of the rule in to account but bases it on the type of system in which the rules would be implemented. This led to the following classification:
1) Rules for data transformation, which are rules that transform data from one format to another, e.g. for the communication between systems.
2) Rules for referential integrity, which represent and control the relationship between entities. It includes database associations, multiplicity, constraints, triggers, etc.
3) Rules for data validation, which are the rules that keep the information (data) in the system consistent.
4) Rules for security, which control access to functionality or data based on roles. 5) Rules for presentation, which allow for dynamic content to be presented to users, 6) Rules for workflow or business process, which are rules that are business process and
workflow related. 7) Rules for decisions, which are used to define the dynamic business-‐level building blocks
of the policies, directives and initiatives of an enterprise. 8) Rules for rating engine, which represent a pricing model to be applied to a given
transaction.
15
4.7 The relationship between the proposed classification and the other classifications
In the following table, the proposed classification is related to the other classifications given in the previous sections.
16
Proposed classification
Constraints Derivation rules Process rules
Busin
ess R
ules group
Structural assertions1
Action
assertions
Condition X
Integrity constraint X
Authorisation X
Derivations X
SBVR
Structural business rules X
Operative business rules X
RuleSpeak
Rejectors X
Producers X
Projectors
Enablers X X
Copiers X
Triggers X
CogN
IAM
Integrity rules X
Derivation rules X X
Exchange rules X
Event rules X
Behavioural rules X
Prim
atek
Rules for data transformation X
Rules for referential integrity X
Rules for data validation X
Rules for security X
Rules for presentation X
Rules for workflow or business process X
Rules for decisions X X
Rules for rating engine X
Table 1: Overview business rules classifications
1 Structural assertions in the Business Rules Group approach are not considered business rules in the proposed approach. Instead, we consider the structural assertions (i.e., terms and facts) to form the basic building blocks for the business rules.
17
In the following figure, the overlap between the different classifications is represented using a Venn-‐diagram.
Figure 1: The different classifications mapped onto each other.
As shown in the figure, the different types of rules in the different classification systems can be mapped to the proposed classification, whereby the proposed classification encapsulates the other classifications in at least one of the categories.
18
When two types of rules of different classifications can be considered as synonyms, a dashed line is used to show the set equivalence. This means in the picture above that integrity constraints in CogNIAM are a synonym for rejectors in RuleSpeak and structural business rules in SBVR. In the Business Rules Group approach, however, constraints are split into action assertions – integrity constraints and action assertions – conditions, and the Primatek classification differentiates between rules for referential integrity and rules for data validation.
Interesting to see is that in the RuleSpeak classification, projector enablers are present in two different categories, namely in the constraint category as well as the process rules category. The reason for this can be found in the fact that an enabler specifies the conditions under which a certain constraint becomes applicable or under which conditions a specific process rule becomes applicable. An example of a rule that makes another rule applicable would be: “if the customer is married, then the name of the partner has to be given” (condition on a mandatory constraint). An example of a rule that makes a process rule applicable would be: “if the customer is a new customer, then the action “register customer” needs to be performed”.
Another type of rule that is crossing the borders of two categories is the CogNIAM derivation rule. A CogNIAM derivation rule can be used as a task in a process. That is, processes often contain so-‐called decision tasks or computational tasks. Decision tasks are tasks that generate an outcome based on information provided as input of the task. In case the decision generates new information by applying a formal prescription, the decision corresponds to a derivation rule. A computational task is a task that “computes” values, and can also be a task in a process. Therefore, derivation rules in CogNIAM cross the border to process rules in the proposed classification. And, by similar reasoning the same holds for rules for decisions in the Primatek classification: rules for decisions can be part of a process, and as such map towards process rules.
It should be noted that “rules for presentation” in the Primatek classification are matched to process rules since these rules describe the manner in which information is presented to the user in the so-‐called user-‐interaction processes, which map to, but are not necessarily the same as, the underlying business processes. Presentation rules based on user-‐interaction processes is under development in the CogNIAM methodology.
Finally, it is worth mentioning that structural assertions in the business rules group do not match to any of the other types of rules in the different approaches. The reason for that is that in most approaches (CogNIAM, SBVR, RuleSpeak, and the proposed classification), the facts and terms are not rules but form the foundation on which rules are build.
19
5 Business rules management versus business rules engine
As introduced in section 3, a business rule management system can be defined as “a software system used to define, deploy, execute, monitor and maintain the variety and complexity of the decision logic that is used by operational systems within an organization or enterprise”[7]. This definition for business rule management system goes beyond pure management of business rules and includes the execution of business rules using a business rules engine as part of the business rule management system. This would imply that in a business rule management system only executable rules are managed. Since management and execution are two different goals, we elaborate between the differences in the following sections.
5.1 Business rule management system (the know)
Business rule management has originated from a need to know and maintain the business rules of an organisation in order for them to be used in an effective and efficient manner. Business rule management therefore involves:
1) Identification of business rules and their properties like e.g., ownership, versioning, applicability,
2) Definition and maintenance of business rules, 3) Definition of the relations between business rules, 4) Ensuring the consistency between all the rules contained in the business rules sets,
and 5) Tracking and tracing of the realisation of business rules in one or more
implementations.
A business rule management system (BRMS) is a system that aids the stakeholder in the process of business rule management. The BRMS provides the means to administrate the business rules and their related properties and should have additional functionalities in order to verify the consistency and coherence of the business rules.
Stakeholders of the business rules management systems are:
1) The business persons who own the rule(s), and 2) The analysts which define and maintain the rules.
Note that, in some cases, both roles are present in the same persons.
5.2 Business rule engine (the how)
Business rule “execution” is the focus of business rule engines. A business rule engine is a software system that executes the business rules in a runtime production environment. The business rules engine can be used to define, test, execute and maintain the implemented business rules separate from application code. The business rule engines functions as pluggable software components that execute the business rules that have been externalized from application code.
A business rule engine always has a business rule management component associated in which the business rules that are to be executed are described. Often these type of business rule management components require a technical definition of the rules as they must be fully
20
automatable. These type of systems are usually less business friendly. Experience shows that the syntax of such a business rule engine is often too technical for the business domain and therefore requires the intervention of a specialist.
5.3 From rules in a business rules management system to realisation
As specified above, a business rule engine system makes use of a technical language which is less intuitive to a business user than the languages used in business rule management systems, which are in most cases a controlled subset of the natural language. With a controlled subset of the natural language we mean that:
1) The rules are stated in a natural language, and 2) These rule statements are expressed in accordance to the regulation (amongst which
the grammar) provided to “control” the natural language. That is, a controlled natural language consists of a set of agreements to which the rules have to comply in order to ensure that there is only one possible interpretation of the meaning of the rules. The set of agreements (i.e., the set of rules) provides the means for developing an automatic mapping between a rule maintained in a rule management system and a possible realisation, by using formal prescriptions (a set of formal transformation rules). This has as advantage that the same structure is always mapped in the same manner to a specific realisation, implying consistency throughout and avoid misinterpretations occurring.
BRMS
Realisation script for, e.g. a service...
Realisation script for, e.g. a BRE
Transformation rules
1. Do x2. Calculate y3. If y = 1 then do b else do c4. Do z5. …
Transformation rules
1. Do x2. Calculate y3. If y = 1 then do b else do c4. Do z5. …
Figure 2: Formal transformation rules define how rules in a business rules management system are
mapped to realisations.
As depicted in Figure 2, one set of rules maintained in a business rules management system can be the source for many realisations. By using transformation rules, the rules maintained in the business rules management system can be transformed in a consistent and interpretation-‐free unambiguous manner to different realisations. Examples of such realisations are services that implement the rules, implementation of the rules in existing systems or e.g. providing the rules as input for a reasoning engine (a BRE). Using the transformation rules, which also form a
21
rule set, it is guaranteed that the same rule set in the business rule engine is always matched in the same way to a specific realisation.
6 Business rules in relation to other disciplines
Business rules management is an efficient and effective mechanism for managing decision logic independently of the realisation of the rules in the different systems. They are however, not to be described in isolation of any of the other disciplines supported by an organisation.
6.1 Business rules management and data management
Business rules and data have a close connection. Already in the 1970s it was recognised in ISO TR9007 that “all relevant general static and dynamic aspects, i.e., all rules, laws, etc. of the universe of discourse should be described in the conceptual schema (the data model)” [13]. It is therefore not surprising that this close connection between data and rules is supported by all visions on business rules, and is one of the main articles of the business rules manifesto (article 3.1. “Rules build on facts, and facts build on concepts as expressed by terms”). Facts are expressed in a structural manner in a conceptual data model, which forms the basis for realisation of a data repository, expressed in some implementation format (like e.g., a relational database, an XSD, …).
6.2 Business rules and business process management
Rules management and process management both aim at improving business agility and performance. BPM and BRM serve fundamentally different and complementary purposes. Usage of both is often required to achieve agility, alignment and compliance.
Business process management is focused on modelling, managing, and potentially executing, the sequence of activities in a business process, separating the process logic from the business logic implemented in applications. Business rules management does exactly the same for business rules: modelling, managing and potentially executing the business logic separately from the implementation.
Extracting the business rules from the business processes and managing them separately from the processes implies that rules can be consistently applied across multiple processes.
Moreover, by isolating the business rules from the processes, more agility can be achieved since changes to the business rules do not necessarily impact the current flow of the processes in which the business rules are used. That is, if the content of the rules change without a change of the structure, a swift change of the implementation of the change can be achieved.
6.3 Service-‐oriented architecture in relation to BPM and BRM
The services that need to be delivered in accordance to a service-‐oriented architecture need to be dynamic, configurable, platform-‐independent and easy to evolve as business needs change. The idea behind services is that the business logic contained within a service can evolve easily without a need to change the interfaces of the service and thus the interaction with other
22
services and applications. Business rules are ideally suited to build highly configurable services since they represent the business logic implemented by the service.
Service orientation in combination with an Enterprise Service Bus (ESB) can minimise the number of implementations of business rules. When a business rule service is executed on a single engine and made available on the ESB, users of other domains can also consume this service. This reduces the number of required transformations as depicted in Figure 2 drastically.
23
7 What kind of rules are managed in a business rules management system?
Not all business rules are maintained in a business rules management system due to the fact that there might be more appropriate places to specify them or because the cost of maintenance exceeds the benefits. That is, while all rules are relevant, they should not all be realised in the same management system. What is of relevance though is the close connection between the different management systems so that, although potentially distributed, there exists one consistent model containing all the rules. In other words, while constraints might be specified in close connection to the data model and process rules in close connection to the processes, each with their own management system, it should be possible to relate all of them in such a manner that the total set of the rules is consistent and coherent.
7.1 Criteria for identification of the rules to be managed in a BRMS
In section 3.4, we defined a business rule as: “a directive or demand, which is intended to influence or guide business behaviour, in support of a business policy that is formulated either in response to an opportunity or in response to a change of regulation imposed by an external entity.”
Based on this definition, we consider business rules to be managed in a business rules system all those rules that have a direct impact on the organisation’s behaviour resulting from a change in policy (e.g., due to a change in vision, mission and/or goals of the organisation). From this perspective, we eliminate those rules that are highly stable over time as rules that need to be explicitly managed in a business rules management system. Of course, preferably they are managed somewhere else than in programming code but they have not the highest priority.
Looking back at the proposed classification in section 4.1, the following can be observed:
1) Constraints are closely related to data and are responsible for data quality, 2) Derivation rules, and in particular information-‐generating decision rules represent
decisions made by organisations, often in response to business policies. 3) Process rules, containing the authority rules as well as the conditions for the processes
have an influence on the execution of the processes. Each type of business rule needs to be managed. However, as explained above, not all rules should be managed in the same environment, but put together, they should result in a global single point of truth; the rules can be managed in different environments but the complete resulting model should be coordinated such that all pieces together form one consistent and coherent whole. This principle is depicted in Figure 3. As shown in the picture, the solid foundation where all the rules build on, is formed by the terms and facts. This foundation is required to ensure a consistent and unambiguous single point of truth.
24
Figure 3: Different types of business rules deserve their own dedicated environment, controlled and
coordinated from one single point.
Based on the classification and based on the different types of business rules, we propose that:
1) Constraints are managed in coordination with data models, i.e., in a conceptual data model,
2) Process rules are managed in coordination with the processes, i.e., in a business rule management system that can be integrated with a business process management system,
3) Derivation rules are those rules that are often called the “automatable” rules, since they represent some business logic that easily changes and is of influence of how the organisation reacts to changes. Therefore, these rules are best managed in a business rule management system for which it is possible to define the formal transformation rules that allow a semi-‐automated, interpretation-‐free mapping to e.g. a service or scripts, as described in section 5.3.
25
8 Rule governance
In order for business rules management to become successful, the governance structure surrounding business rules management needs to be put in place, similar to e.g. the governance surrounding business processes and data quality. Governance relates to the establishment of organizational structures, communication and processes to ensure consistent management of business rules.
The governance process surrounding business rules can be defined as: “a series of business actions and checkpoints indicating who should be doing what and when with respect to deploying business policy and business rules” [11]. The main (sub)processes that make up the governance process include:
1) Rule authoring process: the process that goes from identification/creation of the rule to the analysis and formalisation of the rule. The rule authoring process focusses on formal creation of rules.
2) Rule validation process: the process that is executed to ensure that the rule is validated by all stakeholders before deployment.
3) Rule deployment process: the process to put a business rule in production after validation.
4) Rule monitoring process: the process for monitoring the deployed rules in production, and in case of failure the recovery of the failure up until the rule retirement.
5) Rule change management process: the process that handles the changes of a business rules, in a consistent and coherent manner. The rule change management process is an alternative of the rule authoring process and is followed by rule validation.
A good governance structure surrounding rule management within an organisation is a prerequisite for success; without rule governance, the benefits of rule management initiatives fall short. Including a governance structure aids the organisation in an effective and efficient use of the rules, aids in answering compliance issues as well as supports the risk mitigation processes. Rule governance ensures that rules are treated as first-‐class citizens in the organisation, meaning that their impact and use is visible and traceable throughout the complete organisation.
26
9 Conclusions
For an organisation to maintain (or achieve) the competitive edge and to be compliant to ever changing regulation, it is often required to be able to react in a timely fashion to changes in their immediate environment that affect their business. This can only be achieved if an organisation has a grip on the rules that determine its behaviour; i.e. their business rules.
Explicitly specifying business rules has a positive effect on the organisation’s dynamic behaviour, its overall agility. Changes to rules do not necessarily impact existing processes implying that these changes can be implemented swiftly in a consistent manner implying flexibility and a timely response to changes. This in particular in those cases that the business rules are maintained in a business rules management systems (BRMS) that forms the source of transformation rules that transform the formally described rules in the BRMs to execution scripts in the different target implementations. Especially in a service-‐oriented architecture, this flexibility of change through implementation of the rules in services is what provides an organisation the flexibility it needs.
Business rules do not live in isolation; they should not be studied or managed in isolation of other aspects of the business. In particular, business rules management is highly intertwined with data management, process management and form together with these disciplines the basis for a solid service-‐oriented architecture that provides the flexibility and rapid reaction to change required.
Rules
dataprocesses
Figure 4: rules have an impact on the data and processes and should be described in close cooperation.
In contrast to what many claim, in this paper we do not advocate one single central repository that contains all rules. Instead we propose a distributed approach whereby the constraints are maintained in close cooperation with the data, process rules in close cooperation with the processes on which they act and derivation rules in close cooperation with the services that implement them. Of essence, however, is that the rules are maintained only once and together they should result in a single global model. That is, the rules can be managed in different environments but the resulting model, when combining all the rules, should be coordinated such that all pieces together for one consistent and coherent whole. To achieve this, we advocate the use of the facts and terms as the solid foundation on which all the rules build. This foundation is required to ensure a consistent and unambiguous single point of truth.
27
10 References
[1] SBVR; http://www.omg.org/spec/SBVR/1.1/
[2] Guide Business Rules Project Report, 1995.
[3] Business Rules Group, 1998; www.businessrulesgroup.com
[4] Ross, Ronald G., Lam Gladys, S.W. (2000). Capturing business Rules.
[5] Chisholm, Malcolm (2001). Managing reference data in enterprise databases.
[6] Halle von, Barbara (2002) Business rules applied: building better systems using the business rules approach.
[7] http://en.wikipedia.org/wiki/Business_rule_management_system.
[8] http://en.wikipedia.org/wiki/Business_rules_Approach.
[9] Ross, Ronald G. (2003). Principles of the Business Rule Approach. Canada: Addison-‐Wesley.
[10] Charpentier, Eric (2009). Business Rules: A classification”. www.primatek.ca.
[11] Ross, Ronald G. and Lam, Gladys S.W. (2011). Building Business Solutions: Business Analysis with Business Rules”.
[13] ISO TR9007, Concepts and Terminology for the Conceptual Schema and the Information Base, 1987
28
ANNEX A: Different classifications explained
A.1 The Business Rules Group classification
In their final report, the “Business Rules Group” provided the results of the GUIDE Business Rules Project, which had as one of the objectives to define and describe business rules and associated concepts [2]. The main classification provided by the Business Rules Group is the following:
1) Structural assertions, 2) Action assertions, and 3) Derivations.
A.1.1 Structural assertions
A structural assertion is defined as: “a statement that something of importance to the business either exists as a concept of interest or exists in relationship to another thing of interest”.
Structural assertions come in two flavours, namely terms and facts.
A term is a word or phrase which has a specific meaning for the business, while a fact is an assertion of an association between two or more terms. For example, “customer has account” is a fact associating the terms “customer” and “account”.
A.1.2 Action assertions
An action assertion is a declarative (not procedural) statement that specifies constraints on the results that actions performed in the organisation, can produce. An example of an action assertion is: “Each customer shall have at least one account”.
Each action assertion belongs to exactly one of the following categories:
1) Condition: an action assertion that asserts that if something is true, another business rule will apply (e.g., ”if a customer is registered then the customer’s account number is known”, whereby the “a customer is registered” forms the condition).
2) Integrity constraint: an action assertion that must always be true, e.g., “Each customer shall have at least one account”.
3) Authorization: an action assertion that defines a specific privilege of a user for a specific action. An authorization typically is represented by the sentence: “(only) x may do y”, where x represents a user(role) and y represents an action. For example, “an account manager may create a new account”.
A.1.3 Derivations
A derivation is a business rule that uses either a mathematical computation or a logical induction or deduction to create new facts. A derivation rule is therefore classified to be a:
1) Mathematical computation, or 2) An inference.
29
Note that an inference has some resemblance with a condition (action assertion). The main difference is that in a condition, the “then-‐part” of the condition is another business rule. In an inference, the “then-‐part” of the inference are new facts that become true.
A.2 The SBVR classification
The Semantics for Business Vocabulary and Business Rules (SBVR) encompasses more than only the business rules. It also encompasses a “vocabulary part” which focusses on community-‐specific communication. For the purpose of this paper, the focus lies on the classification of rules, and business rules in particular, as supported by SBVR (clause 12 of [1]).
A rule in SBVR is either a business rule or a structural rule. A business rule is a rule under business jurisdiction, meaning that the business owns the rule and has the authority to change the rule. A business rule is based on a policy. A structural rule, being a statement of necessity can also be a business rule (but doesn’t have to be).
Besides structural business rules, SBVR also recognises the operative business rule. Operative business rules are rules that should be followed but can be violated. An example of an operative business rule is: “a gold customer should be given a reduction of 10%”.
A.2.1 Structural business rule
A structural business rule is a claim of necessity (it is necessary that each customer has at least one account), a statement of impossibility (it is impossible that a customer has no account), or a statement of possibility (it is possible that a customer has more than one account).
A.2.2 Operative business rule
An operative business rule is a guide for conduct or action: a regulation or principle. E.g., it is obliged that a customer’s social service number is known. An operative business rule is also called a behavioural rule. In principle, a behavioural rule can be violated while a structural business rule cannot.
It should be noted that derivation are not supported as such in SBVR. They are defined as a formal definition of a term, using other terms and keywords instead of being classified as a type of business rule.
A.3 The RuleSpeak classification
Ron Ross has introduced in [9] different types of business rules as part of RuleSpeak. RuleSpeak is developed as a natural language to support the business rules approach. In [9], it is specified that RuleSpeak consists of three main components, namely:
4) The structure component which consists of the key concepts and the logical connections between them,
5) The process component which consists of processes that operate on terms and facts, and
6) The rules component which consists of rules that constrain processes to act only in certain ways deemed to be best for the business as a whole.
30
In RuleSpeak, business rules are defined as: “Directives to influence or guide business behaviour”.
Following RuleSpeak, the following main categories of rules is identified:
4) Rejectors, which reject any event that would cause a violation to occur. Rejector-‐type rules address data quality.
5) Producers, which calculate or derive something. 6) Projectors, which produce an event based upon an update event (if this, then that
too). Projectors can be further classified into inference rules or triggers.
A.3.1 Rejectors
A rejector, also called constraint, is any rule that disallows an event if a violation of the rule would result from the event. Rejectors are there to ensure data quality. Examples of rejectors are: “A proposal must be signed before it can be confirmed”. “A customer may place an order only if the customer has an account”.
A.3.2 Producers
Producers are those rules that compute a value based on a function. There are two types of producers in RuleSpeak, namely:
1) Computation rules which computes a value following arithmetic operations. A computation rule provides a precise formula for how a computed term is to be calculated.
2) Derivation rules which derive a truth value based on logical operations.
A.3.3 Projectors
Projectors, also called stimulus/response rules, are rules that take some action, other than rejection, when a relevant event occurs. Such an action might be to create or delete data, enable or disable another rule, set some value or to execute some program or procedure. A projector does not reject events but causes some new event(s) as a result of them.
Projectors are either:
1) Enablers that create or delete instances of data, switch instances of a rule “on” or “of” or “allow” or “disallow” executions of a process or procedures.
2) Copiers which set the actual values of a data element to a specific value (e.g., “the applicable sale-‐tax must be set to 21%)” or which specify what the presentation of an element should be (called presentations).
3) Triggers which cause a process or procedure to execute or a rule to fire.
A.4 The CogNIAM classification
In CogNIAM, business rules are classified to be either:
1) Integrity rules, 2) Derivation rules, 3) Exchange rules,
31
4) Event rules, or 5) Behavioural rules.
In contrast to the approach of the Business Rules Group, the terms and facts, although forming the foundation of the approach as being the basic building blocks for the rules, are not considered themselves as rules.
A.4.1 Integrity rules
Integrity rules (also called validation rules) have as function to restrict the set of facts and transitions between facts to those considered useful. That is, integrity rules are those rules that ensure that the data remains consistent and correct when an event that triggers changes to the data occurs.
A.4.2 Derivation rules
Derivation rules are used to derive (calculate) new information on the basis of existing information. Derivation rules provide the prescription of the manner in which the new information is generated. Note that a derivation rule can be a decision rule (i.e, using if-‐then constructs), a mathematical rule (i.e, a computation using mathematical functions) or a combination of both.
A.4.3 Exchange rules
Exchange rules specify how facts are added, removed and/or changed, whereby the manner is no derivation.
A.4.4 Event rules
Event rules specify under which circumstances a derivation rule or an exchange rule is triggered.
A.4.5 Behavioural rules
Behavioural rules specify obligations. I.e., it are rules that ought to be obeyed but may be violated. These rules may be supplemented by declaring a sanction to be applied when violated.
A.5 The Primatek classification
In [10], a different kind of classification is given, which is not based on the meaning of the rules as expressed above but based on the place where the rule would be implemented. That is, in contrast to the above classifications, the classification given in [10] takes the realisation of the business rule as a categorisation principle. The following classification does not take the meaning of the rule in to account but bases it on the type of system in which the rules would be implemented. This led to the following classification:
9) Rules for data transformation, which are rules that transform data from one format to another, e.g. for the communication between systems.
32
10) Rules for referential integrity, which represent and control the relationship between entities. It includes database associations, multiplicity, constraints, triggers, etc.
11) Rules for data validation, which are the rules that keep the information (data) in the system consistent.
12) Rules for security, which control access to functionality or data based on roles. 13) Rules for presentation, which allow for dynamic content to be presented to users, 14) Rules for workflow or business process, which are rules that are business process and
workflow related. 15) Rules for decisions, which are used to define the dynamic business-‐level building blocks
of the policies, directives and initiatives of an enterprise. 16) Rules for rating engine, which represent a pricing model to be applied to a given
transaction.