Tuesday, June 17, 2014

Business Rule Engine (BRE) Validation Framework cum Engine - Decisioning system

Rules -> What comes to your mind… is it everyday life rules like following traffic rules. Yes very similar.
Take an example from everyday life, let say
Visitor1 goes to Transportation Authority for Driving License, will he get it hand in hand or will there be some form filling and some validations. Yes correct, basic validation let’s say he/she should be above 18yrs.
Visitor2 goes for account opening in bank, again will he get his account number hand in hand or he has to submit to some documents. Yes correct, PAN card will be required.
Now think about automating the above process instead of paper work. These are nothing but some rules that are governing the process/system.
Take an example of simple form, let say we have a form where customer has to fill in few details like “firstname”, “lastname”, “dob”, “occupationDetails”, “addressDeatils”. Now suppose same form is being used by two or more clients and both have different sets of mandatory fields in the above form. So how will you manage now,
1.)    Will you create two jsp pages, yes why not.
2.)  Or some validation on server side with if else conditions

Ok done, tested and deployed and relaxed.

Now what, I got one more client with different set of mandatory fields, no issues I will create one more jsp page or add more if else statements. I am ok with making my code dirty or maintaining different pages.

But being a intelligent developer, I will think of some generic solution, will create one page only and leave the mandatory field set for client to configure. I will ask the client to create rule for whatever fields he wants to validate, problem solved, no changes on coder side.

The term Rule Engine is quite ambiguous in that it can be any system that uses rules, in any form, that can be applied to data to produce outcomes. This includes simple systems like form validation and dynamic expression engines. There are two methods of execution for a rule system: Forward Chaining and Backward Chaining; systems that implement both are called Hybrid Chaining Systems.
Advantages of a Rule Engine
o    Declarative Programming
Rule engines allow you to say "What to do", not "How to do it".
The key advantage of this point is that using rules can make it easy to express solutions to difficult problems and consequently have those solutions verified. Rules are much easier to read than code.
Rule systems are capable of solving very, very hard problems, providing an explanation of how the solution was arrived at and why each "decision" along the way was made (not so easy with other of AI systems like neural networks or the human brain - I have no idea why I scratched the side of the car).
o    Logic and Data Separation
Your data is in your domain objects, the logic is in the rules. This is fundamentally breaking the OO coupling of data and logic, which can be an advantage or a disadvantage depending on your point of view. The upshot is that the logic can be much easier to maintain as there are changes in the future, as the logic is all laid out in rules. This can be especially true if the logic is cross-domain or multi-domain logic. Instead of the logic being spread across many domain objects or controllers, it can all be organized in one or more very distinct rules files.
o    Speed and Scalability
The Rete algorithm,the Leaps algorithm, provide very efficient ways of matching rule patterns to your domain object data. These are especially efficient when you have datasets that change in small portions as the rule engine can remember past matches. These algorithms are battle proven.
o    Centralization of Knowledge
By using rules, you create a repository of knowledge (a knowledge base) which is executable. This means it's a single point of truth, for business policy, for instance. Ideally rules are so readable that they can also serve as documentation.
o    Tool Integration
Tools such as Eclipse (and in future, Web based user interfaces) provide ways to edit and manage rules and get immediate feedback, validation and content assistance. Auditing and debugging tools are also available.
o    Explanation Facility
Rule systems effectively provide an "explanation facility" by being able to log the decisions made by the rule engine along with why the decisions were made.
o    Understandable Rules
By creating object models and, optionally, Domain Specific Languages that model your problem domain you can set yourself up to write rules that are very close to natural language. They lend themselves to logic that is understandable to, possibly nontechnical, domain experts as they are expressed in their language, with all the program plumbing, the technical know-how being hidden away in the usual code.

When should you use a Rule Engine?

The shortest answer to this is "when there is no satisfactory traditional programming approach to solve the problem.". Given that short answer, some more explanation is required. The reason why there is no "traditional" approach is possibly one of the following:
o    The problem is just too fiddle for traditional code.
The problem may not be complex, but you can't see a non-fragile way of building a solution for it.
o    The problem is beyond any obvious algorithmic solution.
It is a complex problem to solve, there are no obvious traditional solutions, or basically the problem isn't fully understood.
o    The logic changes often
The logic itself may even be simple but the rules change quite often. In many organizations software releases are few and far between and pluggable rules can help provide the "agility" that is needed and expected in a reasonably safe way.
o    Domain experts (or business analysts) are readily available, but are nontechnical.
Domain experts often possess a wealth of knowledge about business rules and processes. They typically are nontechnical, but can be very logical. Rules can allow them to express the logic in their own terms. Of course, they still have to think critically and be capable of logical thinking. Many people in nontechnical positions do not have training in formal logic, so be careful and work with them, as by codifying business knowledge in rules, you will often expose holes in the way the business rules and processes are currently understood.
If rules are a new technology for your project teams, the overhead in getting going must be factored in. It is not a trivial technology, but this document tries to make it easier to understand.

With this we come to our topic “Business Rules Engine”.
A business rules engine (BRE) is a software component that allows non-programmers to add or change business logic in a business process management (BPM) system. A business rule is a statement that describes a business policy or procedure. Business logic describes the sequence of operations that is associated with data in a database to carry out the rule.
A business rules engine works by separating execution code for business rules from the rest of the business process management system. This allows the end user to change business rules without having to ask a programmer for help. When a change is made, the engine will evaluate the change's effect on other rules in the system and flag the user if there is a conflict.
·         Business Rule Repository - A database for storing the business rules as defined by the business users.
·         Business Rule Editor - An intuitive user interface that allows business users to define, design, document and edit business rules.
·         Reporting Component/Auditing - An intuitive user interface that allows business users to query and report existing rules.
·         Rules Engine Execution Core - The actual programming code that enforces the rules.

Rules Usages
  • Process rules that automate the routing, assignment, and tracking of work tasks.
  • Decisioning rules of varied types including decision trees, decision maps, and decision tables.
  • Declarative rules that compute values or enforce constraints as other properties change.
  • Transformation rules that map and parse data across heterogeneous IT systems.
  • Integration rules that determine the right system connection to make in each circumstance.

Rule Usages

1.) Validation Framework
2.) Driving Workflow and making decision.
3.) Eligibility Policy Engine
4.) Credit Policy Engine
5.) Scoring Policy Engine
6.) Rule chaining.
7.) Matrix based Rule Execution
8.) Allocation of task and assignment

Business rule engines produce logic, as programming languages do.

Graphical Rules for Greater Efficiency in Development and Maintenance 

Greater Agility Graphical approach to developing and changing rules and their dependencies that is easy to master.carry advantages and a degree of flexibility that may be more beneficial to the business.
More Traceable Easy-to-change rules for dynamic, process-oriented applications that achieve a high degree of auditability.
Assured Quality Test-driven approach of graphical creation/debugging/testing and execution statistics
Reusable Rules Reusable rules/conditions and parameters services are generated, stored in a rule repository

When do i need a business rule engine..??

  • Is there an advantage of your rules being able to be created/edited and tested by business analysts rather than programmers.
  • Is there a need to understand the rules that apply to a specific interaction. (ie, this loan was denied because of rule x, y or z), reason being displayed and values getting audited.
  • Do you need to know what rules are applied to a certain transaction/events/stage movement at a specific point of time.
  • Do you want to be able to test rules outside of the context of the application to ensure the logic is right.
  • Do your rules change on a consistent basis, or do they need to change rapidly.

** Step by Step guide of creating Business Rule Engine will be coming soon….