When is a Business Rules Engine used?
What is the difference between Business Rules Engines and scripting/configuration/customization
A business rules engine, or a business rules management system, should be used when you are trying to implement a decision in your code. But not just any decision. A decision that:
Involves lots of rules
Has rules that change often
Has rules that are complex or interact in complex ways (think lots of nested IFs otherwise)
Has rules that only someone with domain knowledge can understand/verify
Is one that the business people REALLY want to be able to change without your help
Involves using predictive analytics / scores as part of the decision making
These are the kinds of decisions that pay off the use of a business rules management system. Don't start with the rules, start with the DECISIONS.
Business rules are verbose (so business people find them easier to read), declarative not procedural and atomic (so they can be stored, managed and reused like data in a database).
More on why to use business rules here in this piece on why I believe in business rules.
Business rules engines are typically used to provide customizable "IF some-condidtion THEN do-something" sorts of logic to applications. These types of business rules can trigger certain workflows to execute or bubble up event knowledge to higher level rules, causing them to be evaluated.
Using a rule engine also allows for easier separation of concerns by removing the business logic from your code. Rules engines today typically also offer a front-end where users can add new rules without having to modify scripts inside the application.
Rules engines implement algorithms such as Rete (speaking from Drools experience) that make the task of evaluating the rules quicker. The rule engine also provides forward chaining, backward chaining, hybrid chaining, etc. of rules. However, these could be implemented in a scripting language as well. You can achieve some of the same sorts of things with both approaches, but I believe that it depends on the complexity and number of rules as to which avenue you should choose.
Take a look at this link from the Jess project: http://www.jessrules.com/guidelines.shtml
It provides a step-by-step walk through of questions to ask yourself in order to determine if a rules engine meets your needs, or is overkill.
Rules engines can do forward and backward chaining as well as inferencing. Check out Fair Isaac Blaze, Drools or iLog for implementations.
Related
Is there a rules engine that can handle constantly changing rules? The scope of the rules is well defined, but users have the ability to change parameters of rules within that scope whenever they choose to. I don't expect to have more than a couple thousand rules, but they will likely experience numerous changes each time a user joins the system. Should I scrap the Rules Engine idea altogether here or does something exist that meets these demands? I wasn't able to find anything online except an IEEE paper.
Any business rule engine is nominally designed to handle this use case. However, you will find that they all have different takes on what is important and the technology stacks will be different. The above answers for InRule and CodeEffects seem good for environments where .Net is required.
Based on statements in your question, it seems that you are going to have a lot of churn in the rules. I think it is important for you to consider then who will be making these changes and what the governance of the changes will be. These considerations may be more important to you than the technology platform (.net / java / hosted) or the initial implementation effort, actually. Most rule projects should be considered with the on-going maintenance in mind more than the initial development.
In our project we have to implement business logic regarding mapping of certain objects to some actions. We will have a series of conditions for specific types of objects to be verified before a certain action finally gets resolved. In other words for 7 types of objects we can have a series of actions ( from out of almost 45 actions).
We were thinking of using Drools to write down the aforementioned rules. Does anyone have some positive / negative experience with using Drools as far as its efficiency is concerned? There is also the jBPM framework that can be used (if I am not mistaken Drools are used there) – anyone is familiar with that framework? Perhaps you have some other ideas of how to solve the problem?
With regards efficiency, you should have no issues at all with Drools. That sounds like a pretty tiny set of facts and rules to me. The Rete engine on which it is based is almost certainly faster at making decisions than any pile of if-then-else statements you code up yourself. And a particular benefit that I noticed is that response times are extremely predictable.
Obviously all fact models and rules differe, but as an example, the application I'm currently building has hundreds of facts in working memory at any time, and more than 1000 rules. It's able to make decisions about incoming requests in about 20 milliseconds.
The full jBPM framework doesn't sound necessary for what you describe. However, it is good at what it does. For instance there is a process modelling GUI if you're looking to design workflows, and Guvnor can be usable for non-technical rules authors if the technical team puts in some up-front effort on writing DSLs and building decision tables.
For completeness, the main competitors are probably FICO Blaze Adviser or IBM ILog JRules. Generally when it comes to benchmarks those tend to be slightly ahead of Drools, but they are expensive. Admittedly, if you decide to pay for JBoss/RedHat service contracts then it's not much different, but if you're happy to take community support on Drools, then it's free!
My only concern about Drools is that there is no decent GUI for it that a non-IT business people could really use. Lots of products claim that they do provide such UI but it always turns out to be not really true. So, you have to accept the fact that your development team will end up creating and testing all those rules based on decision tables or some other formats.
Other than that, Drools is a great BRE used by governments, banks and large companies.
Drools is very efficient and fast. But as with any technology & framework it will need an investment to integrate into your project and it is not a magic bullet. You need to consider:
How many rules will you have? I would not recommend any rule engine if there is less than 20 rules. It might not justify the effort you will spend for the compexity of adding a rule engine just for 7 objects and 45 actions...
Will you need DSL (Domain Specific Language) capabilities? Ie. will non-technical people write rules? IMHO this is not very usable in Drools in comparison to eg. Oracle OPA. But again I have not seen a non-technical person safely tinkering with a rule system yet. Apart from changing values in a decision table.
How often will your rules change? If you need a centralised system to manage, version, package, test your rules then Drools Guvnor is a very capable product.
jBPM is not a rule engine, it's a workflow engine. Drools is a rule engine. So Drools is what you're looking for.
Drools and jBPM are companion projects: they integrate really nicely if you need workflows with rules.
Drools is good well JBPM is bit complex as compared to other BPMN engines. I would suggest go for Activiti because it is bit easier and integration of anything say Spring, LDAP etc.; with Activiti is easier. Also you can integrate Drools with Activiti.. so go for Activiti as aworkflow engine and Drools for a rules engine.
Rules Engines are often sold under the premise of making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers.
In my opinion, putting into production any code that is not covered by automated tests represents a grave risk. I know that many rules engines are actually a rules management environments, including versioning, promotion between environments etc.but what support they offer to BA for writing tests? I have seen some documents where it seems frameworks like JUnit are integrated into the engine and this is certainly not the type or programming that non-programmer would do.
BA can easily change the rule with business engine, but how easy is for him to write a test that can cover it without the help of a programmer? How is the problem of rules test coverage resolved in practice?
"making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers."
We have been using a commercial rules engine for over 6 years now. We build template applications that are customized as per the customer's (like banks etc) requirements. The customization's are in the form of decisioning rules which are written in business vocabulary. Below are some of the observations that I've made over 6 years
I've never seen any rules customized on the fly in production by any customer. They all go through proper testing in the UAT environment before they are pushed to production. The whole app is not re-deployed, only the business rules are pushed.
Rules are written by the BA's but most of the time they still need to go through the developers for performance tuning purposes because of the execution model that these rules engine use.
I doesn't know about many open source rules engines but for the one we use, we wrote custom eclipse plugins so that that BA's can generate the test cases in the form JUnits
I think most of the rules engines will provide some sort of a API that tells which rules were fired in the form of audit report for a given request. But the challenge for us was to find the test data that can fire a particular rule. We call it as rule relevant data.
Recently, I am reading about the rule engines in JBOSS Drools Manual [ref - 2.2.5. Strong and Loose Coupling]. Below is the excerpt from it 'If your rules are all strongly coupled, the chances are that the rules will have future inflexibility, and more significantly, that perhaps a rule engine is overkill (as the logic is a clear chain of rules - and can be hard coded. [A Decision Tree may be in order]). This is not to say that strong or weak coupling is inherently bad, but it is a point to keep in mind when considering a rule engine and in how you capture the rules. "Loosely" coupled rules should result in a system that allows rules to be changed, removed and added without requiring changes to other rules that are unrelated.'
Does that mean, the rule engine is not suitable option to implement complex business logic [tightly coupled rules or chain of rules].
In my current project, we have chain of rules i.e. outcome of 1 rule decides the outcome of another rule and so on. The application has many internal variables to chain the rules. I thought rules engine might help to handle the complexity with the added advantage of declarative rules and dynamic business logic.
Discussion in this regard will be helpful ...
Some logic just isn't all that easy to get right even if you exactly know the order and nature of the tests you need to perform, and the actions that should result. Examples are Corporate Audits, Means testing for Assistance programs, Insurance regulations, etc.
Most Rules Engines today are beginning to include a Decision Table feature, which in all reality introduces some "limited strong coupling" (I don't know if that is really a term, but it is how I understand the effect in systems such as ILog, Drools, etc.). This is helpful because some tests are just related to other tests and decision tables are far better for structuring these tests than IF THEN ELSE structures.
Corticon (a proprietary Rules Engine) and DTRules (an open source Rules Engine) just toss the whole loosely coupled rules approach, and just build decision tables. The idea is that giving a nice structure for the construction of your decisions (which amount to decision trees underneath everything) is easier for many applications.
"Avoiding strong coupling" has nothing to do with "avoiding complexity".
What the documentation advocates is that you should not call one rule from another, instead, each rule should produce an outcome, and the outcome itself should trigger the next rule in chain. This way rules do not concern with what happens next, and instead they deal with facts (aha!). And if - instead of writing rules for facts - you focus on writing an ordinary flow of procedural logic, you do not really need the added complexity of a rules engine.
The difference is subtle, but not more subtle than rules like "don't put your business logic in view" or "don't put your database access code in your business logic".
In IBM ILOG Jrules there are many ways you can represent your rules.
In plain english like language , if else kind of syntax.
decision table - for a set of value
decision tree - multiple outcomes , branching out.
so you can decide on which way you can use the above three ways which fits to crack your complex rules into a more simpler form.
you can use rule flow orchestration with conditional flow to tackle " outcome of 1 rule will be the input of another rule "
I think it all depends on UI, not on actual logic that the rule(s) contain(s). Remember that most of today's engines are decision-table-mentality-based. And all that "Strong and Loose Coupling" is nothing more than buzz words used as an excuse for a bad UI or lack of it. Normal engine can handle execution of a rule of any complexity. Note that this is my personal opinion, lots of folks out there would completely disagree. So, please don't rush to downgrade my answer, I'm just trying to help :)
The typical notion is that the rule with complex logic would look really "messed up" or even impossible to implement in a decision table. Normally, guys try to combat that by dividing complex rules into smaller simple rules and stack them up into rule sets based on execution priorities.
There are new engines that have decision-table-less UIs by implementing parentheses instead of priorities. Parentheses also help with complexity.
How rule engines are evaluated? What do you test to see if it performs OK or not? Milliseconds per single rule execution? Complexity of a rule? If it's "time per rule", what time is considered to be great/bad? Thanks!
A major selling point of rules engines are speed. The usually compile your rules, rather than interpreting them, otherwise wouldn't it be easier to just write the rules in a simple scripting language? Rules should not take more that a couple ms.
It all depends on what you want to evaluate and what's most important to you.
If the pure execution time of a call to the rule engine is most important, you should run tests with rulesets that are designed in a similar way than you expect them to be. The structure, uniformity and complexity of business rule projects can vary widely from project to project. Because of that, it's impossible to make general statements about execution times. Consider a project with 5000 very uniform rules as opposed to a project with 100 complex and interdependent rules. Different engines will handle these scenarios with varying speed. The way a rule engine handles the selection of eligible rules for execution is another factor that determines the performance.
Another important part of a Business Rule Management System (BRMS) is the ease of development, change and maintenance of the rules. Whether or not there are systems in place for rule governance, management of the rule lifecycle, automated testing & simulation or a simplified frontend for business-user.