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
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 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….
No comments:
Post a Comment