It provides business users the flexibility of reading and changing the rules without development effort.
---
... users who have actually participated in business rule implementation projects can experience distinct unease that is sometimes manifested as resistance. This reaction occurs as a result of what can be called the Black Box Problem...
... users who eagerly adopted a business rules automation solution would also run a shadow set of spreadsheets that replicated the rules they input into the system...
... users had varying degrees of uncertainty about whether they had written the rules correctly... choosing the wrong [database] column... order of operations... order in which rules fired...
... users may not be able to fully articulate and define the rules they use in their business process, and hence cannot include them in the rules they define in the business rules engine...
... a danger that the designer may, perhaps unwittingly, include inflexible hard-coded rules in the rules engine itself... If the users are constrained by functions to only be able to do things in a certain way, they again feel that the business rules automation software is behaving like a black box that they cannot control. This is a particularly devastating criticism for software that is designed to provide users with the flexibility to write their own rules...
... With a rules engine, the users are placed in a position where they must be more self-reliant... there is usually no IT support available in the same way as there would be for a traditional systems development project...
... Failure to appreciate this problem and to add the required functionality can destroy the investment made in building a rules engine...
It's always added complexity with adversarial purposes.
It's true that specifications change faster than software can be completed. That is at the core of the agile manifesto (not to be confused with Agile the industry). There's more than constant change. Part of why specifications are never frozen is how hard it is to specify things at the level of exactness and detail computers require. Vagueness and contradictions are rife, and as programmers one of the reasons we get paid a lot of money is to turn rules into running code. That's another part of the ideas behind the agile manifesto: Get something working in front of the users, adjust what isn't right, and iterate.
Business rules engines aren't magically able to determine what users mean. Someone still has to specify things precisely enough to be executable. The task is difficult enough to require specialized skills: in other words, to require someone who can think like a programmer.
The business user able to specify things in ways computers can execute is so rare as to be near-mythical. What happens when rules engines get deployed, where they make sense, is that there is a team of programmers who are also involved in managing the rules. You might remember the scene in RoboCop 2, where Murphy is so burdened with rules developed by committee he is unable to function meaningfully.
At least one of you who has read this far is about to reply with something about "AI, if not now, at least soon...". I advise pondering carefully before replying.
I think there's great value in empowering your coworkers. Most of us don't know how to, so we end up inventing some gnarly DSL, or a glitchy UI admin panel, or we ask medical professionals to learn to write SQL and then feel very engineery when it doesn't work out. But having seen what non-technical people can achieve with just a spreadsheet and sheer determination, I think we're just not very good at understanding what business rule engines and the tooling around them should be able to do. It doesn't help that the majority of them came around the time of XML and SOAP and Java. So instead of rules we make the users write Jira tickets, and instead of local sandbox experimentation we give them hours of QA.
"I've seen two applications of a well-known commercial Rete rules engine running in production where I work. I'd consider one a success and the other a failure.
The successful application is a decision tree app, consisting of ~10 trees of ~30 branch points each. The rules engine has a UI that does allow business folks to maintain the rules.
The less successful application has ~3000 rules slammed into a rules database. No one has any idea if there are conflicting rules when a new one is added. There is little understanding of the Rete algorithm, and the expertise with the product has left the firm, so it's become a black box that's untouchable and unrefactorable. The deployment cycle is still affected by rules changes - a complete regression test must be done when rules are changed. Memory was an issue, too.
I'd tread lightly. When a rule set is modest in size it's easy to understand changes, like the simplistic e-mail sample given above. Once the number of rules climbs into the hundreds I think you might have a problem.
I'd also worry about a rules engine becoming a singleton bottleneck in your application.
I see nothing wrong with using objects as a way to partition that rules engine space. Embedding behavior in objects that defer to a private rules engine seems okay to me. Problems will hit you when the rules engine requires state that isn't part of its object to fire properly. But that's just another example of design being difficult."
My company is absolutely the second case, and it makes development awful. On top of that because of how complex things have come, business users don't interact with these rules at all, and all the work ends up on the devs.
#1) Conflict of Interest.
It is not in the interest of a wage-earner to implement a system which automates away his/her job. Most engineers would love to take a day to turn simple conditional change and get paid for it. Most business people would also love to own their spreadsheets and be the owner of their logic. Each role prefers to be the gatekeeper of their respective domains as most in-the-weeds folks are paid for their time and not for their outcomes.
#2) Useless Upstream, Dumb Downstream
"the users are placed in a position where they must be more self-reliant".
Oh the naivety! Rule engine projects try to transfer the domain knowledge and business logic from one brain to another brain. Herein lies the problem, you'll never be able to get someone upstream of you to implement the business logic because that's what they pay you to do (useless upstream). People downstream of you don't understand the business logic and cannot be trusted to build it (dumb downstream). What ends up happening is that you build the rule engine for yourself. This is a win for everyone except the rule engine implementer - see #1).
If your rule engine can be updated 2x faster, decision making time should get cut in half. But in practice this does not happen. Instead, you will receive 2x the number of update requests to net out the time. This is the reason people hate building productivity tools for others - because inevitably, the business people say "hey if its so easy to update why dont you do it?"
#3) Outcomes
The key to a successful rule engine is sufficient tooling around the integration of rules engines and "business outcomes". When a rule engine is built with a domain specific outcome in mind, they can be very successful. Financial business logic is often written in excel for very exacting levels of specificity - spreadsheet conditional logic is a rule engine. For engineers, Visual editors provide great integration points for coding a vis-a-vis rule engine which ties into software systems. Klaviyo has done a great job of building a rules engine for marketers with a great UI with outcomes tied to both email marketing and automation. There are several such tools. You need a very high quality domain specific UI which is tied to a specific business outcome.