When should you NOT use a Rules Engine

Question

I have a pretty decent list of the advantages of using a Rules Engine  as well as some reasons to use them  what I need is a list of the reasons why you should NOT use a Rules Engine  The best I have so far is this      Rules engines are not really intended to handle workflow or process   executions nor are workflow engines or process management tools   designed to do rules    Any other big reasons why you should not use them

User · Answer

That s certainly a good start   The other thing with rules engines is that some things are well-understood  deterministic  and straight-forward   Payroll withholding is  or use to be  like that   You could express it as rules that would be resolved by a rules engine  but you could express the same rules as a fairly simple table of values     So  workflow engines are good when you re expressing a longer-term process that will have persistent data   Rules engines can do a similar thing  but you have to do a lot of added complexity   Rules engines are good when you have complicated knowledge bases and need search   Rules engines can resolve complicated issues  and can be adapted quickly to changing situations  but impose a lot of complexity on the base implementation   Many decision algorithms are simple enough to express as a simple table-driven program without the complexity implied by a real rules engine

User · Answer

The one poit I ve noticed to be  the double edged sword  is      placing the logic in hands of non technical staff   I ve seen this work great  when you have one or two multidisciplinary geniuses on the non technical side  but I ve also seen the lack of technicity leading to bloat  more bugs  and in general 4x the development maintenance cost   Thus you need to consider your user-base seriously

User · Answer

GREAT article on when not to use a rules Engine    as well as when to use one       http   www jessrules com guidelines shtml  Another option is if you have a linear set of rules that only apply once in any order to get an outcome is to create a groovy interface and have developers write and deploy these new rules   The advantage is that it is wickedly fast because normally you would pass the hibernate session OR jdbc session as well as any parameters so you have access to all your apps data but in an efficient manner   With a fact list  there can be alot of looping matching that really can slow the system down     It s another way to avoid a rules engine and be able to be deployed dynamically yes  our groovy rules were deployed in a database and we had no recursion    it either met the rule or it didn t    It is just another option     oh and one more benefit is not learning rules syntax for incoming developers   They have to learn some groovy but that is very close to java so the learning curve is much better   It really depends on your context   Rules engine have their place and the above is just another option if you have rules on a project that you may want to deploy dynamically for very simplified situations that don t require a rules engine   BASICALLY do NOT use a rules engine if you have a simple ruleset and can have a groovy interface instead     just as dynamically deployable and new developers joining your team can learn it faster than the drools language  but that s my opinion

User · Answer

I would strongly recommend business rules engines like Drools as open source or Commercial Rules Engine such as LiveRules    When you have a lot of business policies which are volatile in nature  it is very hard to maintain that part of the core technology code  The rules engine provides a great flexibility of the framework and easy to change and deploy  Rules engines are not to be used everywhere but need to used when you have lot of policies where changes are inevitable on a regular basis

User · Answer

I m a big fan of Business Rules Engines  since it can help you make your life much easier as a programmer  One of the first experiences I ve had while working on a Data Warehouse project was to find Stored Procedures containing complicated CASE structures stretching over entire pages  It was a nightmare  to debug  since it was very difficult to understand the logic applied in such long CASE structures  and to determine if you have an overlapping between a rule at page 1 of the code and another from page 5  Overall  we had more than 300 such rules embedded in the code   When we ve received a new development requirement  for something called Accounting Destination  which was involving treating more than 3000 rules  i knew something had to change  Back then I ve been working on a prototype which later on become the parent of what now is a Custom Business Rule engine  capable of handling all SQL standard operators  Initially we ve been using Excel as an authoring tool and   later on  we ve created an ASP net application which will allow the Business Users to define their own business rules  without the need of writing code  Now the system works fine  with very few bugs  and contains over 7000 rules for calculating this Accounting Destination  I don t think such scenario would have been possible by just hard-coding  And the users are pretty happy that they can define their own rules without IT becoming their bottleneck   Still  there are limits to such approach    You need to have capable business users which have an excellent understanding of the company business   There is a significant workload on searching the entire system  in our case a Data Warehouse   in order to determine all hard-coded conditions which make sense to translate into rules to be handled by a Business Rule Engine  We ve also had to take good care that these initial templates to be fully understandable by Business Users  You need to have an application used for rules authoring  in which algorithms for detection of overlapping business rules is implemented  Otherwise you ll end up with a big mess  where no one understands anymore the results they get  When you have a bug in a generic component like a Custom Business Rule Engine  it can be very difficult to debug and involve extensive tests to make sure that things that worked before also work now    More details on this topic can be found on a post I ve written  http   dwhbp com post 2011 10 30 Implementing-a-Business-Rule-Engine aspx  Overall  the biggest advantage of using a Business Rule Engines is that it allows the users to take back control over the Business Rule definitions and authoring  without the need of going to the IT department each time they need to modify something  It also the reduces the workload over IT development teams  which can now focus on building stuff with more added value   Cheers   Nicolae

User · Answer

I get very nervous when I see people using very large rule sets  e g   on the order of thousands of rules in a single rule set    This often happens when the rules engine is a singleton sitting in the center of the enterprise in the hope that keeping rules DRY will make them accessible to many apps that require them   I would defy anyone to tell me that a Rete rules engine with that many rules is well-understood   I m not aware of any tools that can check to ensure that conflicts don t exist   I think partitioning rules sets to keep them small is a better option   Aspects can be a way to share a common rule set among many objects   I prefer a simpler  more data driven approach wherever possible

User · Answer

In my experience  rules engines work best when the following are true    Well-defined doctrine for your problem domain High quality  preferably automated  data to help drive most of your inputs Access to subject matter experts Software developers with experience creating expert systems   If any of these four traits are missing  you still might find a rules engine works for you  but every time I ve tried it with even 1 missing  I ve run into trouble

User · Answer

I will give 2 examples from personal experience where using a Rules Engine was a bad idea  maybe that will help -   On a past project  I noticed that the rules files  the project used Drools  contained a lot of java code  including loops  functions etc  They were essentially java files masquerading as rules file  When I asked the architect on his reasoning for the design I was told that the  Rules were never intended to be maintained by business users     Lesson  They are called  Business Rules  for a reason  do not use rules when you cannot design a system that can be easily maintained understood by Business users    Another case  The project used rules because requirements were poorly defined understood and changed often  The development team s solution was to use rules extensively to avoid frequent code deploys     Lesson  Requirements tend to change a lot during initial release changes and do not warrant usage of rules  Use rules when your business changes often  not requirements   Eg - A software that does your taxes will change every year as taxation laws change and usage of rules is an excellent idea  Release 1 0 of an web app will change often as users identify new requirements but will stabilize over time  Do not use rules as an alternative to code deploy

User · Answer

I don t really understand some points such as   a  business people needs to understand business very well  or  b  disagreement on business people don t need to know the rule   For me  as a people just touching BRE  the benefit of BRE is so called to let system adapt to business change  hence it s focused on adaptive of change  Does it matter if the rule set up at time x is different from the rule set up at time y because of  a  business people don t understand business  or  b  business people don t understand rules

[rule-engine] When should you NOT use a Rules Engine?

Examples related to rule-engine