Business rules are an essential and omnipresent building block in nearly every business process. Business rules define how a company's business works by describing business policies or key business decisions. So, they are the fundament on which the business logic and processes are built. Thus, rules should be considered as shareable and centrally managed BPM artifacts like other essential resources, such as service and data descriptions, used in the context of defining process-driven architectures.
Ideally, the management of business rules is done centrally and independently from the business flow logic, for example, in a Business Rules Management System (BRMS). The separation of the decision logic from the business process flow logic is essential to ensure comprehensibility and flexibility of business processes.
Unfortunately, the decision logic is often implemented as part of the business process flow logic today! Within this chapter, we will show why this is not a good approach.
In the previous chapter, we discussed how to involve human actors in automated business processes to fulfill decision requests. This chapter will outline how IT can support a transparent enterprise decision management by automating business decisions. Even if human decision making is not replaceable completely, as shown in the previous chapter, in this chapter, we will come up with ideas about when decision automation is possible and effective. We will do the following:
- Describe the characteristics of business rules and their relation with BPM
- Explain how to identify and assess business rules, that is, business rules candidates
- Discuss how to design, organize, and implement business rules
- Depict the Oracle Business Rules' design time as well as runtime architecture and its concepts
- Discuss best practice approaches to implement business rules
Why business rules within BPM are important?
Before understanding why rules are important within BPM, let's have a look at what a business rule is and what its characteristics are.
About rules
A business rule is an atomic assignment, which takes either true or false as its value. Rules have to be kept simple and not contain programming logic. Rules are declarative expressions, usually in an if-then style notation, consisting of a condition and an action. The action is only evaluated if the defined condition is met. Because of these characteristics, rules are easily readable and understandable for nontechnical people, regardless of the knowledge background, compared to the rules logic implemented in Java, for instance.
The following snippet shows a simple example for a business rule. It shows the characteristics previously discussed:
IF
rentalCar.milesDriven > freeMiles
THEN
return (rentalCar.milesDriven - freeMiles) * 0.5
The rule, taken from the car rental scenario, is used during invoice creation and deals with the calculation of additional fees for a car rental case if a customer exceeds the maximum number of free miles. As a result, customers will be charged for every mile that was driven over the free miles limit, with $0.5 per mile. The rule comes up in the aforementioned if-then style notation, where we have a condition, which is the Boolean expression after the if keyword, and the action is executed only when the condition evaluates to true.
After this short excursion to the characteristics of rules, let's get back to the actual question as to why the business rules are important within Oracle BPM.
Rules and Oracle BPM
Business process flows are usually not straightforward because daily business isn't so either and additionally, it changes rapidly today. This is challenging for companies and makes business process flows become more complex due to new requirements defined by the business or restrictions coming from the market that have to be incorporated with existing process models. The implementation of such changes can be done by adapting the business process flow to meet the changed conditions.
As an example, let's assume that the marketing of our car rental agency intends to ensure customer retention by providing discounts to particularly good customers that have the customer status platinum. The resulting business requirements are handed over to the IT, which applies the changes to the car rental process. The excerpt from the following process shows the changes to the process model:
Figure 1
Before writing the invoice, the customer status is checked. If the customer is a platinum customer and the car has been returned in time, a total discount of at least 3 percent is granted to the customer. On the basis of the service-oriented Oracle BPM approach, the cost and time to bring the changed process into production is adequate; marketing is happy.
At first sight, everything seems to be fine. But it is not! What if the marketing campaign is limited, the granted discount is changed, or the campaign is extended to other customers too? The answer is that the process model has to be adapted every time the requirements change. This is a design failure because intentionally it was planned to change the invoice creation, that is, the underlying calculation rules, depending on the customer status.
Admittedly, the example is a little exaggerated. What should be demonstrated is that business decisions are often hidden within business processes and their flow logic that might lead to the following risks and problems:
- Risk of duplication
- Missing transparency
- Inconsistencies in rule usage and definition
- Inflexibility of processes
- Mixing of flow and decision logic
- Increased process complexity
The risks of duplication as well as lack of transparency may be fatal because both likely cause inconsistencies regarding rule usage and rule definition. Depending on a company's business, rules will change more or less frequently. When rule changes have to be applied, all concerned places must be changed. The challenge is to find these out. Furthermore, it is costly in terms of time and resources. Resources are usually rare, so a detailed analysis of rule usage is nearly impossible. In consequence, only a shallow analysis can be done, increasing the risk of inconsistencies because not all concerned processes, and, therefore, not all rules defined within will be adapted. This may cause serious consequences for the business, such as monetary or image losses and further legal sanctions, when being noncompliant with legal restrictions.
A further challenge arises from the release and change management when changes to rule and process artifacts have been applied and should be transported into production. When rules are defined within business processes, the flow and business logic are versioned and packaged together in a single application. So, a change in a rule causes a new process version and vice versa. Furthermore, a redeployment of the process application is needed. This causes two major challenges:
- The migration strategy for already running process instances
- The versioning of rules and process changes
Usually, business process services are stateful and long running. Therefore, when redeploying a process due to changes in the contained business rules, one main point is to clarify what should happen to the already running process instances. Questions that will come up about this point are:
- Should new rules directly be used?
- Should new rules be used by new instances only?
- Should new rules be used until a specific date?
Depending on the affected processes, dealing with the corresponding business cases and process owners may be complex and time consuming and has to be repeated every time a business process is changed. Additionally, different processes may be concerned with a single rule change, so different migration strategies could be required.
For the reason that rule changes cause new process versions, the comprehensibility regarding the changes is restricted. Rule changes, which affect more than one business process, may lead to different versions for business processes. This is confusing since the reason for the new process revisions is a change in the same business rule. Depending on the frequency of changes within the business rules and the chosen migration strategy to run process instances, several versions of the same business process may be deployed in parallel. From a governance point of view, this is not acceptable in terms of an accurate business processes life cycle management and the corresponding release management.
Additionally, business processes are obviously more inflexible. The processes' complexity may also grow when extensive checks using several attributes from the corresponding process data objects have to be performed. Testing these changes in isolation without retesting the whole business process flow is impossible in this scenario. Furthermore, the error analysis at runtime is difficult and lengthy.
In summary, it has to be concluded that the way the decision logic is implemented within business processes has an impact on the flexibility, maintainability, and the future-proofing of process-driven applications. The benefits that companies hope to gain from a holistic BPM strategy, such as an increase of business agility or transparency in terms of the business process flows, are not achievable over the long term, when business rules are not centrally managed. A more flexible approach is needed, which optimally supports a company's BPM strategy.
Note
The separation of the decision and the business process flow logic allows the separation of responsibilities referring to process modeling as well as the decision logic declaration. To assure reusability and to avoid duplication of already existing rules, these have to be combined and centrally provided in a service-style fashion. Taking these few points into account when developing process-driven applications will guide companies to the expected success, with process transparency on the one hand as well as flexible and easily adaptable applications and processes on the other hand.
The information from the current article points out why rules are important within Oracle BPM. This is because the business logic explained in rules define essential policies and constraints of the business that a company is running. Rules are important for decision support, regardless of whether these are handled with fully automated decisions or manual ones. Flexibility and easy adaptability is important due to the dynamic nature of most companies' daily business. The time to market for changes applied to the business policies and constraints must be as short as possible in order to ensure competitiveness.
