Business Rules are everywhere in business applications. Business policies, user interface’s validation rules, elevation/escalation rules, dynamic assignment rules, data loading rules etc. It is safe to say – behind every successful business application, there are business rules.

Business rules brings in transparency and agility to business applications. Infusing quick, sustainable customization of rules leads to business agility. Along with it, if the system allows business analysts and auditors to view the translated (code) version of business policies and validate the precision of translating business policies as business rules, then such applications are termed as transparent applications.

Business policies and there effective implementation can be possible with a business rule engine. This blog post drills into rule engine and define the qualifiers for choosing rule engine. Blog also covers Oracle Business Rules (OBR), Oracle Policy Automation (OPA) and showcase difference between OBR and OPA. For sake of convenience, this blog is divided into three parts – part one delves into rule engine, part two drills into OBR, OPA and algorithms while part three focus on OPA vs OBR.

Blog covers following topics –

• Part 1
  • Rule engine and qualifiers
  • Declarative vs Imperative model
• Part 2
  • Oracle business rule (OBR) and Oracle Policy Automation (OPA)
    • OBR
    • Technical Glance
    • Terminologies
    • Approach to write rules
    • Rules structure
    • OBR architecture
    • Rule activation
    • Forward chaining system
    • Charm of Declarative rules
    • Ordering algorithms
    • Underlying algorithms
    • Performance tips
  • Oracle Policy Automation – quick link
• Part 3
  • OPA vs OBR and qualifiers

Part # 1 - Rule Engine and Qualifiers

A software system that provides an engine for the execution of business policies (as rules) is termed as business rule engine (BRE). Business policies can be legal regulations, business policies, validation rules, translation rules; operational rules like assignment rules, escalation rules etc. A BRE allows creation, modification and maintenance of such business policies as separate entity from the business application (code) and data.

Business applications like workflows, user interfaces and supporting components like integration etc. are meant for executing business functions. However, Business rules induces knowledge to business applications and business rules produces knowledge. Example, a 22 year male is buying a sports car of red color. Such business scenario can lead to events (via underlying messaging framework) to create business knowledge (example evaluating regulatory laws, insurance laws etc.). However, a workflow or a business application will only reach to such event. Maybe, that event is captured by the workflow, which again triggers business rules to route such approval requests to someone authorized. Here, following are the interesting pieces –

1. Workflow can be replaced, by any workflow (from any vendor).
2. Business policies (as rules) remain the same.

Here, workflow represent the business logic and business rules represent the business policies. But there is a separation between them. This allows greater reuse of the business rules, allows centralization of rules, and allows separate lifecycle of creating, modifying and maintaining the rules.  From the design and architecture perspective, separation of business logic from business policies (as rules) is the recommended approach. However, from product prespecitve, many vendors offers native integration. Example Oracle’s BPM/SOA integrated with Oracle business rules (OBR). Alternatively, applications can also connect with rules engines like Oracle policy automation via a service invocation or APIs.

Business have business rules and rule engine offers the core to execute ‘business rules’. Business rules are the coded version of business policies, which leads to a business decision. Example – If Car is red and car is a sports car and the driver is a male less then 22 years of age then increase insurance premium by 15 %.

Based on rules scheduling, there are different types of rules engine – forward chaining and backward chaining rules engine. Backward chaining are goal driven and facts are resolved to reach a specific goal. Forward chaining rule engine are either inference rules or reactive rules. Inference rules uses condition-action model to represent rules while reactive rules detect events, processes event patterns and reacts based on it example complex event processing.

Rule Engine Qualifiers

Weather you need a rule engine or not, can be gauged with matching your use case and requirements and weighing the benefits of rules engine vs complexity of not having a rule engine. Rules can be embedded in the programs itself or can be in a rule repository, which is used by rule engine. Rules engines are not singular, they comes with tools and GUI to manage, edit rules and options to deploy, version and administer rules. Defining nature of rule engine, comes from the rule algorithms that drives it. Example RETE, LEAPS etc. They connect facts with rule, determines the order, chaining, conflict resolution and the execution of the rules. This section, we enlist few of the qualifiers for using rule engine.

Following are the qualifies for using Rule Engine

1. Centralization of Knowledge - Rule repository and rule engine offers a central ledger of knowledge. Such ledger is executable and acts as single truth for business policy. Just glance though the decentralized and distributed blockchain technology, which relies on smart contracts. Here, smart contracts are the centralized authored set of rules for interacting business parties.
   • Multi-channel service delivery – Common rule repository will allow organization to use same repository of rule(s) for internal, external and integrated use.
2. Chaining – Chaining is a property of rules that allows action part of a specific rule to changes/alters the condition part of other rules, which ultimately leads to change in the state of the system.
3. Is your domain knowledge in abundance? Domain knowledge workers knows about processes and rules and are often non-technical. Rule authoring tools allows authoring rules via rule authoring tools.
4. Declarative Rule - Rule engine allows you to specify, “What needs to be done”, instead of “How it needs to be done”. Means, rules are simple expression which can be verified (application transparency).
5. Separation of data, logic and rules - Data is the core which logic is in the business logic layer, while rules are separate. This essentially means – data, logic and rules are decoupled. It has its own set of advantages and disadvantages, depending on your analysis. Example, a business can argue of maintainability issue with rule engine, however the advantage that rule engine offers is the central repository for rules and easies the rules maintenance and helps you inch towards the future of ‘Autonomous’ organizations. Decoupling logic and rules allows ease of rule maintenance, as changes to rules need to be reflected at just one central place.
6. Agility – Rule engine in its standalone mode (e.g. Determination eligibility tool or assignment & escalation rules) can typically be implemented much more quickly than a full custom solution. The full solution may be a multi-year implementation, but the organization could build, deploy and test an eligibility determination tool or assignment and escalation tool relatively quickly before the full system is ready to go.
7. Power of Algorithms - Proven algorithms like RETE, LEAPS etc. are efficient at pattern matching.
8. Rules authoring - Tools and applications like JDeveloper, Composer applications etc. allows you to edit, manage and change rules. Also offering audits and empowers business analysts to do the same.
9. Ease to Read - You can write rules in natural language, simple if-else statements, decision matrix etc. These are understandable logic to technical and non-technical audience.
10. Does your logic changes often and Do you need rules agility? Logic can be simple however, rule changes often and business sis seeking rules agility.
11. Beyond business empowerment, there lies Declarative vs Imperative – Organizations are skeptical about the rule engine’s pitch on the empowerment of business users to specific the rules and modify it. It is plausible yet it works out on a case by case basis.  However, the point here is, even if it does not works well for business users, there are several factors that should incline business towards rule engine such as - declarative vs imperative models.

Declarative vs Imperative Model

We discussed about imperative and declarative model above, hence it is important for me to delve into it, in this section.

Imperative model consists of sequenced commands with loops, conditions. Essentially, imperative model focus on HOW, where the program dictates HOW to do it. On the other hand, declarative model consists of rules, which have a condition and an action. Declarative model focus on WHAT and defines what needs to happen instead of how it needs to happen. Imperative model involves righting extensive code with many steps to solve problems and to reach decisions (desired results). These code instructions are dictating system HOW to perform something. Codes can turn out so overwhelming and focus gets shift towards the code and its maintenance rather than rules. Besides that, such code are distributed and maintenance of it will soon turn into a nightmare. On the other hand, rule engines are declarative computational model.

Rule engine (declarative computational model) have following advantages –

• They have framework, offers native integration with underlying infrastructure,
• They offers a development environment and they offers business and IT round trip.
• Enables separation of rule engine from data and business logic. Separation of rule has its benefits like separate development cycle for rules and later those rules can be integrated with business logic.
• They are based on algorithms and suites for deterministic or non-deterministic use cases.

No Rule Engine (Imperative computation model) has following disadvantages –

• Imperative model will lead to lot of code example Java code with loops, functions, libraries etc.
• Disparate applications may have contradicting logic.
• These are codes PRETENDING to be a rule engine. This will result into a system where rules are ONLY maintained by IT and not business users.
• Imperative model sounds appealing when certain technical resources (skills) are in abundance, however this  ‘masquerading rule engine’ leads to complicated structure.
• Debugging will be nightmare, ordeal for maintenance.
• In addition, as it grows, determining the overlap between rules will time consuming and error prone.
• With Imperative model, business policies become lost in such implementations. Due to the basic nature of imperative programming, business policies need to be defined in a declarative form. Requirements need to be translated into sequential execution flow. This translation is costly, error prone, hard to trace and difficult to maintain.
• Imperative model will lead to complex scenarios and add complexity of writing logic to maintaining the ordering of rules, conflict resolution, chaining etc.

Declarative models allows expressing business policies (aka rules) in simple logic or natural language, allowing reasoning and reaching decisions more obvious to those, who author and maintain policies/rules. Ordering, chaining, conflict resolution etc. of policies is automatically taken care by the rule engine, which takes care of correct evaluation of the business policies.

Part # 2 – OBR and OPA

Following section covers Oracle Business rules, offers a glimpse to Oracle policy automation (OPA) and compares them from various use case perspective.  Forward chaining System, Inference Cycle, declarative models of rule engine are exclusively added in below section to allow readers to correlate above rule engine section with OBR and OPA sections below.

Oracle Business Rules (OBR)

When an application can be view by business analyst or auditor and they can determine that an application can precisely implement’s business policies, it can be termed as transparent application. Example insurance, human resourcing, financial services etc. OBR offers efficient development and deployment of business rules. OBR consists of rule authoring tool for defining rules, an SDK for rule access and a rule engine for execution of rules.

Technical Glance

Oracle business rules adds flexibility to applications and processes by empowering analysts and process owners to define, edit business rules.  With OBR, application’s business logic is separate from rules, allowing agile rule maintenance and creates empowered business analysts and process owners. The Oracle Business Rules includes following components –

1. The rule editor,
2. Rule browser,
3. Rules engine and
4. Rule repository for rule discovery, governance, versioning, traceability and availability across the enterprise.

Users can use business rules editor [rules designer or rule composer] and rules are stored and managed in a central business rules repository. You can reference pre-defined business process rules within the modeler. The Business Rules activity in the business process model gets converted to a decision service that in turn invokes the business rules engine in the executable business process. Business users can change these business policies on the fly via an intuitive web browser interface without having to redeploy or re-implement the business process.

Terminologies

Business rule comprises of following –

1. Rulesets – A set of condition and actions that results into outcome of the rule.
2. Facts – These are the data objects used by the ruleset.
3. Decision function – It's the reference to the code that executes the rules.
4. Functions – These are optional and are called in the ruleset.
5. Globals – Usually the constants (data objects) used in the ruleset.
6. Valuesets – Range or list of values used in the rule’s condition.
7. Links – These are links to other business rules dictionary.

The Oracle Business Rules environment is implemented in a JVM or in a J2EE container by the classes supplied with rl.jar. The RL Language command-line interface provides access to an Oracle Business Rules RuleSession. The RuleSession is the API that allows Java programmers to access the RL Language in a Java application (the command-line interface uses a RuleSession internally).

An RL Language ruleset provides a namespace, similar to a Java package, for RL classes, functions, and rules. In addition, you can use rulesets to partially order rule firing. A ruleset may contain executable actions, may include or contain other rulesets, and may import Java classes and packages. An RL Language rule consists of rule conditions, also called fact-set-conditions, and an action-block or list of actions. Rules follow an if-then structure with rule conditions followed by rule actions.

• Ruleset - In OBR, ruleset is a container for If-Then rules and decision tables. Ruleset offers a namespace, which is similar to Java packages. Along with it, you can use rulesets to order rules firing.
• Facts - Oracle Business Rules (OBR) are written in terms of facts types, where each fact is an instance of a fact type. They are the prerequisites to rule. You must have facts (created or imported) before authoring rules.  In OBR, factType is a type definition in data model while fact is an instance of that type.  Rule designer allows you to define variety of fact types based on Java class, Oracle RL, XML schema and ADF BC view objects. Rules are written in terms of factTypes.
• Decision Function - Decision functions are contracts to invoke rules from SOA/BPM/Java composite/code. Decision functions contract includes fact types, rulesets and output fact types.
• Rule Dictionary - Rule dictionary is an XML file (.rules files) that stores rulesets and data model and you can link dictionary with other dictionaries. It is In OBR, dictionary are containers for facts, functions, global value sets, links, decision functions and rulesets. You can create more than one dictionary and each dictionary can contain any number of rulesets.
• SDK - Rules SDK offers decision point API, which allows applications to access, create, update and execute rules in OBR dictionaries.

Approach to Write Rules

OBR rules can be modelled using follows ways –

• IF/THEN rules, and
• Decision Tables - Decision Tables are multiple related rules expressed in a spreadsheet-like format.

If/Then rules written using following approaches –

• As general rules - General rules use a pseudo-code language to express rule logic
• As verbal rules - Verbal rules use natural language statements to express rule logic. The verbal rule condition is a business phrase that can specify one or more logical tests

Note - Rules and Decision Tables are grouped in an Oracle Business Rules object called a ruleset. You group one or more rulesets and their facts and valuesets in an Oracle Business Rules object called a dictionary

Rule Structure

Rule comprises of rule condition and rule actions. Rules are used to evaluate conditions and specify actions when the conditions are met (evaluate to true).

• Rule Condition - A rule condition is a component of a rule that is composed of conditional expressions that refer to facts.
  • General rule example - if Driver.age < 21
  • Verbal rule - IF driver is an underage driver
• Rule action - The Oracle Rules Engine activates a rule whenever there is a combination of facts that makes the rule's conditional expression true. In some respects, a rule condition is like a query over the available facts in the Oracle Rules Engine, and for every row that returns from the query, the rule activates.

Note – Rule activation is different from rule firing.

The rule condition activates the rule whenever a combination of facts makes the conditional expression true. In some respects, the rule condition is like a query over the available facts in the Rules Engine, and for every row returned from the query the rule is activated.

The rule action aka rule THEN part contains the actions that are executed when the rule is fired. A rule is fired after it is activated and selected among the other rule activations using conflict resolution mechanisms such as priority. A rule might perform several kinds of actions. An action can add facts, modify facts, or remove facts. An action can execute a Java method or perform a function which may modify the status of facts or create facts.

Note - Rules fire sequentially, not in parallel. Note that rule actions often change the set of rule activations and thus can affect which rule fires next.

Rule Activation

A rule action is activated if all of the rule conditions are satisfied. There are several kinds of actions that a rule's action-block might perform. For example, an action in the rule's action-block can add new facts by calling the assert function or remove facts by calling the retract function. An action can also execute a Java method or perform an RL Language function. Using actions, you can call functions that perform a desired task associated with a pattern match.

The Oracle Rules Engine first matches the facts against the rule conditions of all rules as the state of working memory changes. A group of facts that makes a given rule condition true is called a fact set row. A fact set is a collection of all the fact set rows for a given rule. Thus a fact set consists of the facts that match the rule conditions for a rule. For each fact set row in a fact set, an activation, consisting of a fact set row and a reference to the rule is added to the agenda (the agenda contains the complete list of activations).

Rules fire when the Oracle Rules Engine removes activations, by popping the activations off the agenda and performing the rule's actions.

The Oracle Rules Engine may remove activations without firing a rule if the rule conditions are no longer satisfied. For example, if the facts change or the rule is cleared then activations may be removed without firing. Further, the Oracle Rules Engine removes activations from the agenda when the facts referenced in a fact set row are modified or the facts are retracted, such that they no longer match a rule condition (and this can also happen in cases where new facts are asserted, when the ! operator applies).

Oracle Business Rules provides high performance and easy to use implementation of Business Rules technology. It provides easy to use authoring environment as well as a very high performance inference capable rules engine. Oracle Business Rules is part of the Oracle Fusion Middleware stack and will be a core component of many Oracle products including both middleware and applications.

OBR Architecture

For internet based business applications, there are three primary layers for applications – presentation layer (user interface aka display layer), business logic layer (middle layer) and policy layer (rules engine layer).  This is ideal for rule enabled application, policy logic is separated from business logic and its written as business rules (if-else, decision matrix or declarative form).  Business logic can be written in Java or Java based technology etc. while rules are authored as business policy and implemented as set of rules, which are executed by a rule engine.

Below diagram shows the architecture of OBR. Here, business policy are executed in rule engine, where facts are analyzed and results are returned. Rule authoring GUI [or applications using rules SDK], allows rule creation, which are stored in rule repository and rule engine refers to this repository for rules execution.

Oracle business rule is written in Java and is integrated with XML and Java. OBR constitutes of following components – Rule engine, Rules SDK and Rule authoring tool. Authoring tools offers if-else, decision matrix and English-like paradigm for declaring rules.

Forward chaining System and Inference Cycle

In OBR, the rule-based system is a data-driven, forward chaining system. The facts determine which rules can fire so when a rule fires that matches a set of facts, the rule may add facts and these facts are again run against the rules. This process repeats until a conclusion is reached or the cycle is stopped or reset. Thus, in a forward-chaining rule-based system, facts cause rules to fire and firing rules can create more facts, which in turn can fire more rules. This process is called an inference cycle.

A rule-based forward chaining system consists of the following:

• The rule-base: Contains the appropriate business policies or other knowledge encoded into IF/THEN rules, verbal rules and Decision Tables.
• Working memory: Contains the information that has been added to the system. With Oracle Business Rules you add a set of facts to the system using assert calls.
• Inference Engine: The Rules Engine, which processes the rules, performs pattern-matching to determine which rules match the facts, for a given run through the set of facts.

OBR offers charm of declarative rule

With OBR you can use declarative rules, where you create rules that make declarations based on facts rather than coding. Here is an example of declarative rules:

IF a Driver is a Premium customer, offer them 20% discount

IF a Driver is a Gold customer, offer them 10% discount

Advantages of declarative rules -

• Statements are declared without any control flow.
• Control flow is determined by the Rules Engine.
• Rules are easier to maintain than procedural code.
• Rules relate well to business user work methods.

When a rule adds facts and these facts run against the rules, this process is called an inference cycle. An inference cycle uses the initial facts to cause rules to fire and firing rules can create more facts, which in turn can fire more rules. For example, using the initial facts, Rules Engine runs and adds an additional fact, and an additional rule tests for conditions on this fact creating an inference cycle:

Ordering Algorithms - Order of rules

Oracle Business Rules uses working memory to contain facts (facts do not exist outside of working memory). A RuleSession contains the working memory.  Each RuleSession includes one Rule stack. The RuleSession's ruleset stack contains the top of the stack, called the focus ruleset, and any non-focus rulesets that are also on the ruleset stack. The focus of the ruleset stack is the current top ruleset in the ruleset stack.

The Oracle Rules Engine sequentially selects a rule activation from all of the activations on the agenda, using the following ordering algorithm:

1. The Oracle Rules Engine selects all the rule activations for the focus ruleset, that is the ruleset at the top of the ruleset.
2. Within the set of activations associated with the focus ruleset, rule priority specifies the firing order, with the higher priority rule activations selected to be fired ahead of lower priority rule activations (the default priority level is 0).
3. Within the set of rule activations of the same priority, within the focus ruleset, the most recently added rule activation is the next rule to fire. However, note that in some cases multiple activations may be added to the agenda at the same time, the ordering for such activations is not defined.
4. When all of the rule activations in the current focus fire, the Oracle Rules Engine pops the ruleset stack, and the process returns to Step 1, with the current focus.

Algorithm – Underlying enabler

The Rete algorithm, invented by Charles Forgy in 1979 PhD thesis was based on the ‘fact’ that the facts in the rule engine's working memory change slowly over time through a series of inference cycles. 

Facts about RETE algorithm -

1. RETE caches previous rule conditions. Caching previous rule condition evaluation results avoids the re-evaluation of all rule conditions when a small change is made to working memory.
2. Hence, it is good for those applications where rules are NOT changed frequently. For business rules, where they changes frequently, do not benefit from the use of a Rete algorithm while incurring the overhead of the algorithm's memory consumption characteristics.

The Non-Rete algorithm (NRE) is an alternative to the Rete algorithm that consumes less memory than the Rete algorithm. For business rules use cases it will result in improved performance. The core of NRE algorithm is a new rule condition evaluation approach. The majority of the rules engine is unmodified and shared across the Rete and NRE algorithms.  The externally defined semantics of the existing Rete algorithm are preserved by the NRE algorithm.

Facts about NRE –

• NRE is a simpler internal rule representation.
• NRE results in byte code generated for rule tests, rule actions, and user defined functions.
• NRE offers more efficient modify operation.
• With NRE, rule conditions not evaluated until the containing ruleset is on the top of the stack. After initial evaluation, re-evaluation occurs on fact operations as needed.
• With NRE, ability to avoid unnecessary re-evaluation when rulesets are only present on the ruleset stack once during rule execution.

Rete vs Non-Rete

Following is a quick comparison of RETE vs No-RETE algorithms -

• In the Rete algorithm, rule conditions are evaluated when fact operations occur (assert, modify, retract). In the Non-Rete algorithm, rule conditions are evaluated for the first time when the ruleset is on the top of the stack, then on fact operations after that.
• Rule firing order. There are cases where the rule firing order is not defined, for example when a single fact activates multiple rules at the same time and the priorities are identical. In these cases, the order in which the rule activations fire may be different.

Switching to NRE

In OBR designer, NRE algorithm can be selected in the dictionary settings panel under preference tab. SOA and BPM applications will automatically handle the switch of algoritms. For JEE applications, the algorithm selection will need to be specified when the RuleSession or RuleSessionPool is created.

Oracle Business Rules uses working memory to contain facts. Facts do not exist outside of working memory. A RuleSession contains the Oracle Business Rules working memory.

Quick performance tips for business rules –

Some bonus to the developers -

1. OBR rule engine is efficient when the facts are based on RL class / Java Beans. Facts is the data n which rule performs its reasoning.
2. Flatten fact type, means flatten the facts to single dereferences. Example account.user.address has multiple object dereference and it is efficient to flatten it to single dereference. Example if facts have hierarchical structure then use assetXPath to asset object hierarchy to asset account and user as fact types.
3. Code rules with emphasis on avoiding side effect – Rule engine try’s to build a RETE network and RETE network operations are built as facts are asserted, modified or retracted. During this RETE network building, rule conditions are evaluated more/less times depending on the rule conditions. If rule conditions have side, effects like changing a value of the facts used as rule fact or changing state. This might lead to rule conditions evaluation multiple times, which hits the performance.
4. Avoid expensive operations – Avoid rules that access database (directly from rule engine) or operations that involves I/O (disk/network).
5. Visit Ordering of rules – Reordering of rules can improve performance.  As a recommended rules, try placing the facts, that are not expected to change, before the facts that might experience changes. Placing non-changing facts as first clause improves the ‘time’ of rules evaluation. Another recommended approach is to place the facts (as first fact clause), which have fewer facts then other fact clauses in the rule condition. Esentially place the rules which might match fewer facts first. This will reduce memory usage and enhances response time.

Oracle Policy Automation

OPA is a rule engine designed to offer consistent and auditable advice across channels and business processes by capturing rules in natural language Microsoft Word and Excel documents and building interactive customer service experiences called interviews around those rules.

This blog goes into drills into OPA. Please follow below link to read more about OPA –

https://documentation.custhelp.com/euf/assets/devdocs/cloud19b/PolicyAutomation/en/Default.htm

Oracle Policy Automation – quick glance from Algorithm perspective.

Oracle Policy Automation provides complex eligibility and policy inferencing algorithm for forward chain inferencing. This is well suited for making decisions based on legislation modeled in natural language.

Difference between RETE and Linear Algorithm -

Following are the advantages of linear inferencing over the Rete algorithm -

1. Easily handles multiple, simultaneous changes to input data. This makes it better suited to real-world processing scenarios that include transactional processing and batch data upload from a database or interactive applications.
2. Minimizes per-session memory usage. Less memory is required to service high performance applications with heavy concurrent usage.
3. Better exploits modern processor architectures. In particular, the linear inferencing algorithm’s space-efficient data structures increase the use of the onboard processor cache to  provide much-higher performance.

Part # 3 - OPA vs OBR

If you are reading part # 3, you are already convinced the need for a rule engine. So, welcome to part # 3.

Choosing rule engine is a case-by-case assessment. This section, we discuss about the qualifiers to choose Oracle Policy Automation (OPA) vs Oracle Business Rule (OBR). Following are the qualifiers to choose between OPA and OBR -

• Do you need complex determinations, decisions, recommendations and calculations?
  • Do you need guidance or advice tools where you want to publish questions and users can see questions based on their circumstances?
  • Are there clear determinations to-be made based on pre-determined rules?
  • For determination, recommendation and advisory use case, OPA is the best fit.
• Can the goals be defined effectively?
  • If goals are defined effectively, then OPA is a fit.
  • Example - Is the person eligible for, entitled to, liable for, required to...? or What is the amount of benefit, compensation, tax, payment, discount...? or How do I report/claim/return/file/onboard...?
  • If the goals can be expressed in above terms, OPA is the solution.
  • One more example –
  • 
• Does rules involve triggering alters, routing and escalation?
  • In this case, use native OBR solutions with processes, as they are more efficient than OPA.
• Do you have an optimization problem or eligibility determination case? Use OBR for optimization problems and use OPA for eligibility determinations.
  • Example there are 100 widgets and 200 people in a group. Each person may have one or more widgets based on certain criteria about each person’s position in the organization.
  • Alternatively, assignment of BPM tasks needs to be automated based on certain attributes of person such as title and district.
  • Alternatively, escalation of tasks need to be performed based on certain input values such as dollar amount. For such optimization case, OBR is the idea choice as this is a case of non-deterministic nature and OPA is not a fit for non-deterministic cases. 
• Deterministic vs Non Deterministic scenario?
  • Non-Deterministic - In a non-deterministic algorithm, system may produce different result for same input. Example, if input contains title as Appraiser and district as North, then the task need to be assigned to AppraiserNorth group. Maybe later, this changes to a different group or role.
  • Deterministic - If you have a problem of deterministic nature example determining eligibility, OPA is more suitable. For deterministic algorithm, system will produce same output for same input. Example you have rules to determine the eligibility for a specific type of widget. Alternatively, you have a business function rule for ownership transfer (example below).
  • 
  • OPA is a nice fit for deterministic problems.

Refer following diagram for a quick glance to the qualifiers -

Conclusion

Today, compliance with complex regulations or intricate company policies is a substantial challenge for many organizations. Rule engine plays an important role in driving compliance with these rules.

• If you need to externalize business rules, supports rule agility and empower business & product owners to change rules then you should consider rule engines.
• If business decides to adopt and embrace rule engine as part of strategical solution then they should be ready to acquire skills in design, development using rule engine. Consider it an investment, because with AL, Blockchain and all the modern technologies, business are fast-forwarding to Rules Based Organizations aka Autonomous Organizations.

No rule engine and the act of ‘masquerading rule engine’, surprises me the most as there must be a great reason why rules are termed as “business rules”. Hence, I recommend to avoid imperative model and custom rule engine as they are only masquerading rule engine. A rule engine should be for the business users, by the business users and of the business users.