Introduction to Business Rules Management
Let us start by understanding some key concepts around business rules.
What are Business Rules?
Business rules can be defined as the key decisions and policies of the business. Rules are virtually everywhere in an organization; an example is the rule in a bank to deny a loan for a customer if his or her annual income is less than $15,000. We can generally categorize business rules under the following categories:
- Business Policies: These are rules associated with general business policies of a company, for example, loan approval policies, escalation policies, and so on.
- Constraints: These are the rules which business has to keep in mind, and work within the scope of while going about their operations. Rules associated with regulatory requirements will fall under this category.
- Computation: These are the rules associated with decisions involving any calculations, for example, discounting rules, premium adjustments, and so on.
- Reasoning capabilities: These are the rules that apply logic and inference course of actions based on multiple criteria. For example, rules associated with the up-sell or cross-sell of products and services to customers based on their profile.
- Allocation Rules: There are some rules that are applicable in terms of determining the course of action for the process, based on information from the previous tasks. They also include rules that manage the receiving, assignment, routing, and tracking of work.
Business Rules Anatomy
To understand the anatomy of a business rule, we can divide a business rule primarily into the following four blocks:
- Definitions of Terms: This helps in providing a vocabulary for expressing the rules. Defining a term acts as the category for the rules. For example, customer, car, claims, and so on define the entities for the business.
- Facts: These are used to relate terms in definitions with each other. For example, a customer may apply for a claim.
- Constraints: These are the constraints, limitations, or controls on how an organization wants to use and update the data. For example, for opening an account, a customer's passport details or social security details are required.
- Inference: This basically applies to logical assertions such as 'if X, then Y' to a fact, and infers new facts. For example, if we have a single account validation rule (if an applicant is a defaulter, then the applicant is high-risk), and we know that Harry (the applicant) has defaulted earlier on his payments for other bank services, we can infer that Harry is a high-risk customer.
Automating Business Rules
As we discuss the externalization and automation of business rules, it's important to understand the distinction between implicit and explicit rules. An implicit rule can be viewed as a rule that is a part of a larger context within the system. It's like multiple rules that are implemented in traditional applications to implement decision logic, for example, assessing the risk level for a loan. Its implementation is usually part of the application it is being developed for, and is never considered beyond the scope of the application, perhaps to be re-used.
So Typically, in the IT world, these implicit rules are embedded within the complex application code and spread across multiple systems, making it extremely difficult to introduce changes quickly, and without creating a domino effect across systems. Some of these issues can be resolved by implementing a Business Rules Management System (BRMS) in collaboration with the BPM system in place. This allows the decision logic, which is being used by the process during its execution, to be driven by a central repository where all the rules are stored and managed. This repository provides a way to abstract the decision logic from the applications, and helps in managing this logic centrally, allowing for better management and flexibility for change and re-use. Hence, these rules are explicit in nature.
For the loan approval example, business rules such as these would traditionally be embedded in application code, and might appear in an application as follows:
public boolean checkAnnualIncome(Customer customer)
boolean declineLoan = false;
int income = customer.getincome();
if( income < 10000 )
declineLoan = true;
The above example shows that this rule is obviously difficult for the business users to understand. In today's world, with the need for an organization to be agile, (considering our previous example) the business has to wait for weeks before a small change can be implemented by IT. What is required is the ability of the business users to define and control their own rules, and to be able to get the changes out in the market faster. Business Rules Management and related technology tries to solve this problem.
Automating Business Rules for Business Issues
Automation of business rules via BRMS is ideal for use, where the following issues are being faced by an organization:
- Dynamism and Volatility: Companies need to repeatedly change business policies, procedures, and products to meet the market needs. In this case, the rules change very dynamically, and having a BRMS can help in implementing these changes faster, and reducing the time to market and cost of implementation.
- Time to Market: In this case, the organization might want a particular set of changes to be released quickly due to market pressure, or to gain a competitive advantage. So, Even though the rules are not changed very often, a delay in their implementation could lead to a serious business loss. In this case, the organization needs to have the ability to get these changes in quickly, without roadblocks, which can be addressed by a BRMS.
- Regulatory Compliance: Failure to comply with regulatory requirements such as Anti-Money Laundering (AML) laws can result in millions of dollars in fines, and legal issues for the organizations. To solve these issues, institutions can combine business rules with SOA to create an effective strategy for enforcing compliance. Business rules technology helps in implementing these rules quickly, and helps them to be kept up–to-date across an enterprise.
- Business Participation: There could be rules which might be better off being controlled and owned by the business users. In this case, a BRMS can expose certain rules to be managed and edited by selected business users, providing an easy to use interface. Rules related to product configuration, customer eligibility, discounts and so on, are some examples where business users can manage the rules, and change them as required by changing scenarios.
- Complexity: Some scenarios, such as complex product and service pricing, require extremely complex dependencies between several rules to implement the scenario logic. These kinds of rules are best suited for implementation inside a BRMS rather than a procedural language, as is being done traditionally. Telecom Fraud Management, for example, is an area where rules management is being used along with BAM to identify potential frauds. There are similar applications in credit card and banking industries.
- Consistency: Rules managed centrally provides a more consistent way of managing certain policies requiring re-use and consistency across the enterprise. This is especially true in cases where inconsistency was an issue due to multiple applications, databases, and different lines of businesses.
Business Rules Management, BPM, and SOA
Business Rules Management, BPM, and SOA share a synergistic relationship, especially, when used together to provide agility to an organization. The term 'Agility' can be defined as "the ability of an enterprise to sense and predict change in their environment and respond quickly, efficiently, and effectively to that change". Agility, requires the organization to be flexible enough in introducing change and in modifying their current operations, to achieve higher levels of performance or output. A process-driven approach to SOA allows business users to introduce changes to the process for faster execution, and with less cost. This value is amplified by using a Business Rules platform alongside process orchestration. If we look at the BPM reference architecture again, rules functionality features in various layers of the architecture, in the initial rules discovery phase, during process mapping, and in its orchestration in the SOA environment.
Business Rules-related technologies have been in the market for a number of years now. However, with the acceptance of BPM and SOA as enablers for increasing an organization's agility, today's enterprises are increasingly looking at using rules management to externalize their rules. Business rules management helps automate decisions and apply policies within processes. Automation of these decisions requires determining the meaning of a given situation, and applying a business policy in response to this. Business rules platforms provide tools to define this 'reasoning' logic for use by either developers or business analysts, and business stakeholders.
Organizations are looking at Business Rules Management to deploy rules related to policy decisions, work allocation, compliance and control, business exception management, and even data validation. For example, a major financial services company uses business rules to apply privacy and anti-fraud policies to all of its transactions. Even more, these Business Rules are being considered as an asset for an organization that should be managed centrally and re-used across departments and systems, instead of being hard-coded into an application.
So, it is important to ensure that business rules have a place in your SOA. Carefully defining and exposing your rules as services will enable all of the applications and services within your architecture to have simple access to a common rules repository. From an SOA perspective, before beginning a business rules implementation, you should:
- Incorporate a business rules platform into your SOA: This would be a service-enabled repository of your business rules, where instead of data you would maintain and execute rulesets using a business rules engine.
- Create standards and best practices for developing business rules: To maximize benefits from your rules implementation, you should focus on developing common standards and best practices for discovery, design, development, and interfacing of your rules. Some of the best practices for writing and designing business rules are:
- Declarative: Business rules should be declared, and not stated as procedures as in coding. How a rule will be enforced should not be part of a rule definition. For example, "If the customer is a premium customer, offer him further 5% discount."
- Precise: It's easier for business rules definitions to be misinterpreted due to the use of natural language syntax by business. One business rule should be open to only one interpretation, and would need rephrasing if it was found to be ambiguous.
- Consistency and non-redundancy: Business rules should be consistent and not conflict other rules. Similarly, you should look out for business rules that are redundant.
- Business Focused and Owned: Business rules should be declared using the business vocabulary so that they can understood by relevant business stakeholders. Avoid using technical jargons in business rules. Also business rules are best left under the ownership of the business, community, as that is the source for the rules.
Key Considerations for Selecting a BRMS
The following are some key considerations when selecting a BRMS to work with BPM and SOA:
- Standards-based Integration capability: The ability to integrate with the SOA landscape using a service layer.
- Business User Interface: The ability to provide the capability for business users to access and modify business rules through a user-friendly interface.
- Rule Language: The ability to provide support for natural languages for easily expressing a complex set of rules.
- Performance: The ability to provide support for high-volume transactions for mission-critical applications, which is normally measured in terms of the number of rules processed per second.
- Rules Monitoring and Reporting: The ability to feature support for rules debugging, rules reporting, and real time monitoring of rules.
- Rules Repository: The ability to provide a centralized repository for storing all rule-specific artifacts. The repository should also support change management by storing different versions of rules, and providing audit capabilities.
Key components of a BRMS—A Brief Look into Oracle Business Rules
Typically, a BRMS will comprise four main components:
- Business UI: This is a user interface component for writing and editing business rules. Typically, it will be a web-based interface for business users to log in and access existing business rules, create new ones, and so on.
- Rules Development Environment: Developers will be working in this environment to convert business rules defined by business users into code that can be implemented in the business rules engine. This will be also an environment where the service layer for the rules will be defined and implemented for integration with other applications and SOA components.
- Rules Repository: This will be a centralized repository where all rules-related information will be stored.
- Rules Execution Engine: This is the heart of the rules management system and will be responsible for executing the business rules in the run time environment. In SOA terms, this component will receive request for rules processing from the business process orchestration environment, based on which, it will run appropriate rules and provide decision information that will be sent back to the orchestration layer.
Oracle also provides a suite of components under its Oracle Business Rules product to support rules management and execution, which are as follows:
- Oracle Rule Author: Rule Author provides a web-based graphical authoring environment that enables the easy creation of business rules via a web browser. The application developer uses Rule Author to define a data model and an initial set of rules. The business analyst uses Rule Author either to work with the initial set of rules, or to modify and customize the initial set of rules according to business needs. Using Rule Author, a business analyst can create and customize rules with little or no assistance from a programmer.
- Rules Engine: This is the heart of the rules system and executes and manages rules in a proper and efficient manner. This allows inference-based rule execution, based on the very popular Rete algorithm. The Rete algorithm is an efficient pattern-matching algorithm used for rules and facts, and stores partially-matched results in a single network of nodes in current working memory, allowing the rules engine to avoid unnecessary rechecking when facts are deleted, added, or modified. Oracle's rules engine provides a data-driven forward-changing system. This means that the facts will determine which rules can be triggered. When a particular rule is triggered, based on pattern matching within a set of facts, the rule may further add new facts. The new facts are again run against the rules as an iterative process untill it reaches an end state. This allows rules to be interlinked and triggered in a cycle, also referred to as an inference cycle.The rules engine also provides a web service interface with its SOA environment using 'Decision Services', which is available in a JDeveloper environment during the coding of business processes in BPEL. This can also be used to make a web service call to rules running in the rules engine. It also exposes a Rules API, which is based on JSR 94, a runtime specification for rules engines to integrate business rules application with other applications in an organization.
- Rule Repository: A rule repository is the database that stores business rules. The Oracle rules repository allows rules to be grouped as rulesets, and make it part of the rules dictionary in a central repository. These dictionaries can be versioned for better governance. Oracle's rules repository supports a WebDAV (Web Distributed Authoring and Versioning) repository and a file repository.
- Rules SDK: This allows users to develop and integrate the Rules Repository in to a custom authoring environment. This component also allows the development of a customized UI for business users to access and update the Rules repository, if required.
Implementing Business Rules—The Business Rules Development Process
We can take the approach of modeling the rules as part of the BPMN process flow, using decision points or gateways. We can also manage these rules (especially their business logic) either through a tool or by using simple tools such as spreadsheets, before importing them into a rules repository.
The process we are defining here allows business users to map a process flow using BPMN, and use either gateways or specialized activities (as provided in Oracle BPA) to specify a rules decision point. This is nothing more than a BPMN activity extended by the tool during export to BPEL. We would like to see more support for business rules being modeled in the BPMN specification, although at the moment, it is not supported. There are other standards initiatives, such as SBVR (Semantics of Business Vocabulary and Business Rules) by the Object Management Group, that might be worth considering if you are looking at evaluating standards around definition and development of business rules.
As an approach for BPM, it is essential that we view the rules as an integral part of business process, and enable a top-down flow of information from business to IT. This allows the business users to specify the details of workflows and the associated policies, procedures, and constraints at the process levels, and these can then be interpreted as rules during implementation. This is represented by the following diagram, where we can see the various layers of business rules implementation:
In the business layer, the business process is being developed using BPMN, and rules can be identified as decision gateways or activities. The business analyst will typically maintain a list of business rules discovered during the business process definition stage. The combination of BPD and rules specifications will be an input for the technical teams.
During implementation, the IT teams will maintain and manage the business rules with a development life cycle as for any other application. Typically, this will include analyzing the business requirements as part of the process, designing the data models for rules implementation, exposing the service layer from the business rules engine to integrate with the orchestration layer developed for the business process, and testing the deployed rules.
To understand rules development in the Oracle BPM suite, we can follow the steps shown below:
- Rules Harvesting and Discovery: At this stage, the business analyst and business communities will go through a process of understanding the various rules the organization currently possesses in relation to the given business process. This can mean understanding the various policies and procedures the company follows, as well as identifying rules embedded in existing systems. Many organizations go through a series of interviews and requirements workshops to identify the rules affecting the business process that is to be modeled. This process will also allow a variety of input information, such as policy documents, existing system's functional specification, and so on to identify the potential rules, to be structured in to logical groups
Analyze/Model Business Rules: This is not about what is implemented as business rules, but what is not. As rules are virtually everywhere, there is a tendency to deploy all rules as business rules. An important part of business rules analysis is ensuring that the correct set of rules are managed and controlled by the business.
Although BPMN does not provide any specific construct for specifying rules, they are usually represented either through the gateway logic, for workflow related rules, or via the use of a specific extension available in the process modeling tools. For example, with Oracle BPA, we can use the business rules function to enter details about the associated business rule in the process. Let us take a simple example to explain this concept. In this case, we are modeling a business process to decide eligibility of a home loan for an applicant. The process is represented by two business activities in Oracle BPA (Assess Credit Worthiness to check the credit background of the applicant and Assess Loan Eligibility), where a decision is made to decide which bank, and what interest rates will be applicable to the applicant.
Export Process and Rules: At this stage, after modeling and analysis of the process and rules, the BPEL for the BPMN model can be generated to incorporate the changes in to the process maps. This can be achieved by sharing the model in Oracle BPA with the JDeveloper environment using a process blueprint. The blueprint will provide details about the business process and the rules-based information, which can be used for configuring the business rules in BPEL.
At the moment, the exported blueprint for the business rule activity does not get translated to decision services in BPEL. It only creates a business scope in BPEL that can be modified further by IT to add detailed implementation information
- Implement Rules: The skeleton for the business rule specified in the process models is now available. We can represent this as a decision service in BPEL. An IT developer can now modify the decision services to create links with the rules engine, and implement the changes for the process along with the associated rule. As we can see, we are adding two 'Decide' activities to create interfaces with the external decision services.In this case, once we deploy the process CheckCreditWorthiness and AssessLoanAdvise during process execution, a service call will be made to the rules engine for the respective decision services
The attributes for the rules function can be specified here, to be used later as reference by other stakeholders in business and IT.
The business rules function also allows the business users to add details regarding the business rule, if required. This will allow the IT teams to use this information when configuring the data model for the business rules services in Oracle Rules Author, and modifying the BPEL to call these decision services.
In this case, we are using a direct connection between the decision service and the Oracle Business Rules component using an available adapter. We will establish a connection to the repository and select the Ruleset or function to call using this wizard.
After the decision services have been called, we have created a human task in our BPEL to allow a user approve the loan based on the response from the rules engine.
From the Oracle Business Rules side, Oracle Rules Author will be used to define these business rules and will be configured to provide information based on service calls made from the decision services in BPEL. To access the Rules Author, we can use the link available in the Oracle SOA console.
The Rules Author screen provides various tabs to start defining our Rules Definitions.
We can first start by creating a Rules Repository, which we want to be used for our example. We can either choose to connect to a file-based rules repository for managing rules in static files, or we can use a WebDAV-based repository. Let us use a file-based repository in this case. You can choose to either create a new Repository file or load an existing one.
The rules can now be configured by choosing the appropriate Dictionary and Rulesets. In this case, we will take an example of the rules we have created as a sample for loan approval. We start by opening the file-based repository where our rules are stored, and load an existing dictionary. In this case, the existing dictionary we have is called HomeLoanOffer.
We usually start by creating Facts that will be used by the Rulesets. In this case, we have created a set of XMLFact by importing the XML schema for HomeLoanOffer.
We are now in a position to create a Ruleset, as in this case, we are carrying out a simple check to see if applicant's credit rating is more than 200 points. In this case, the rule sends a response to the bank employee to approve the loan.
These rules, as we mentioned, will be available to the BPEL process as decision services during orchestration.
In a practical business situation, we would have a series of complex rules to be executed as required during the process orchestration.
In this article, we discussed the externalization and automation of business rules,the distinction between implicit and explicit rules, and the anatomy of a business rule.We also saw some of the key considerations while selecting a BRMS to work with BPM and SOA,key components of a BRMS,and implementation of business rules using the business rules development process.
If you have read this article you may be interested to view :
- Introducing Business Activity Monitoring
- Business Process Orchestration for SOA
- Using Business Rules to Define Decision Points in Oracle SOA Suite: Part 1