I find myself explaining what a rule engine is very often. Here’s my answer, and some thoughts on where a rule engine can fit into your technology plan in really ground breaking ways. What is a Rule Engine? Funny question because rules are basically a part of every software, in some …
Notice: This article is maintained for historical purposes. The Bixly Automate/Nebri OS platform that Bixly built, and this article features, is no longer available. Checkout Serverless Providers as an alternative.
I find myself explaining what a rule engine is very often. Here’s my answer, and some thoughts on where a rule engine can fit into your technology plan in really ground breaking ways.
Funny question because rules are basically a part of every software, in some way or another. A rule engine doesn’t really seem to exist as a stand-alone category of software, unless you consider Expert System/Inference engine to fill the role. In the Expert System category you have advanced researchers building highly efficient tree/node/chaining/branching reasoning tools for areas like AI.
This really isn’t what I am looking for in a rule engine though.
The traditional rule engine/Expert System scene is quite old, institutionalized, and doesn’t play nice with existing tools. No, that’s not going to cut it. A rule engine to me is something that thinks and operates much like human reasoning, emphasizing rule evaluation rather than procedural execution. A rule engine hosts the rules you have written and takes actions according to these rules. Luckily there are tools that do this! Our product represents one approach. Drools represents another approach for Business Rules Management, while IFTTT has yet another.
For this article I coming down from the Expert Systems stratosphere and focusing on rule engines as a system that take your events, evaluate them with If-Then statements, and take action on them. I place more emphasis event-driven programming and accessibility rather than algorithmic efficiency.
Rule engines are useful to me when they can become a robot administrator! Trained (programmed) to handle repetitive tasks intelligently, based on the rules I program into it.
A referee on a soccer field is just like a rule engine: he/she is programmed with a set of rules that everyone playing must follow. Now a referee gets information by watching the game. A rule engine gets its information by evaluating any data you have provided it. Some examples of incoming data/events:
The referee example also illustrates when it makes more sense to use a rule engine over another approach. You would write one script per soccer “law”, and there are (let’s say) 17 laws in soccer. This is very easy! Programming the same soccer referee functionality with a standard programming environment (imperative and linear rather than event-driven and asynchronous) would require much more code and nested if statements that bread bugs! The rule engine paradigm, in theory, allows you to just write the very core logic, so called business logic, to create software. Additionally, each rule is completely modular, not caring at all about any other rules in the system, yet completely in line with them. Stop reading here if you loathe modularity!
Let’s run through a small example system that would be used in a car rental agency for automating its workflow and team. You can use the very same concepts to control your IOT or smart home devices or within an existing software. Even Complex Event Processing (CEP) or Business process management (BPM) or various types of operational analysis can be handled by a rule-engine. Back to our example though. We will assume the information will by inputted by the employee behind the rental desk. The owner/manager of the car rental agency would be the one to define the rules of the company. Let’s say these ones are in place:
If car returns let Barry know to clean it
If car mileage is 4,000 miles past last oil change, schedule a new one
If a new oil change is scheduled, mark the car as unavailable to customers
Those rules get into the system in various ways. In some systems you use a spreadsheet or a visual designer. With Nebri you program them in Python with a if-x-do-y pattern. It doesn’t matter which system you choose, the results go like this:
Additionally, you can continue to build in complexity (rather than complication) without understanding the other rules. By adding only one more rule/script, you get to benefit from 100% of the existing rules automatically. For example:
If listing cars, hide the ones that aren’t available
One rule, as shown above, might have marked a car unavailable because it needs an oil change. This new listing rule is completely unaware of the other rules in place, and completely compliant with what your company needs. Maybe another script marked it as unavailable because it’s currently being rented.
If iBeacon in car is off the lot, mark the car as unavailable
Wait! It gets even more fun.
If iBeacon in car is off the lot, and customer payment doesn’t exist for this car, alert management
Management will know that the iBeacon might have a dead batter, or maybe the car got stolen. Most likely someone will have taken it off the lot without following some proper procedure, like marking it for repair. But management will know! And the process can be expanded with another couple rules the same day.
Another important quality that will help you adopt a rule engine is a great interface. One fore humans and machines. That would in include a UI, various APIs, and more. A rule engine without a simple email interface, or the ability to quickly text someone or update a value in a remote database is something to avoid.
This gets to the heart of the matter. Sometimes non-rule-engine solutions are the best, no doubt. But if you rule engine can easily connect to people and your existing services, you should certainly consider this approach. Let me point out though where rule-engines just destroy alternatives:
I run a tech company in California and that perfectly fits the definition of complex. Many people, many clients, many preferences and processes and schedules. I found myself deciding between two main paths to better manage the company: Control everything via software or strengthen what was already working with software. The first option would best be handled with Business Process Management (BPM) software. In fact we desperately tried that path and you can read about our experiences. The second path is a much smarter approach to systems thinking. It’s best done with with a rule engine in fact because it fully embraces a non-linear approach to building software. In other words;
Should I define exactly how we on board a new client (linear, BPM style) or should I just make sure that certain things happen if a new client signs up (non-linear)?
BPM systems work for lots of people, don’t get me wrong, but not for quick moving agile companies in emerging markets. BPM is just too limiting and top-down. Introducing a new rule into the company is easy. Introducing a brand new 100% working and 100% complete (BPM) processes is just impossible for us.
Isn’t it more simple to define a rule that says “turn off the lights at this time”? That’s a rule. In your home automation setup, you might even take it further so rules interact in new ways, creating emergent order. Here’s some rules that would do that:
That’s just lights. You can easily connect any hub/device with an API. A good starting place is our Hub Review page. Here’s one more example: automating your home.
This is interesting because programmers sometimes don’t get rule engines at all, or they love them. Not much room in the middle. To those that haven’t any experience with a rule environment, they see a rule approach as useless. “I write in rules all day! Why do I need a new system?” There are also a large group of programmers that love rule-engines so much they program them on their own time. Checkout our list of rule centric software.
Yes, you can write code to accomplish the rule engine example that I gave above. However, it’s very difficult to accomplish our car rental example via traditional (imperative) programming approaches with the same power. You see there are hidden benefits to the three very small rules in our car rental “app” if you will. Like, you can wash the car before or after (hence non-linear) the oil change, and the rules are still applicable. Also, you have a full history (as events) of WHO marked the mileage, when, and what customer used it before the fact. That’s included because every transaction (event, API call, whatever) that hits your system goes down in history so your rules can react to it and so you can troubleshoot them. That means trouble shooting is built into the platform as an exact log of what happened, or didn’t, and why.
So when someone says they can just write code and they don’t need a rule engine when you know the situation calls for it, just be ready to point out the features that you have for free by choosing the right platform. That’s not to mention, this car rental example is a fully functioning system with only three small scripts. No database or interface or server needed. Just think when you have….10 scripts/rules!
A more accurate question to ask is: Can I write this software faster with or without a rule engine?
It’s the best choice when you can comprehend the software better in rules rather than fully specifying a software build out. If you can define with a dozen rules the functionality you need, and a comparable software spec is that many pages, go with rules. When you your software spec is simple, or you need platform optimizations, or speed is more important, traditional software might be a better fit. I wouldn’t (currently) write high end games with rule engine.
It’s also the best choice when you need a generic solution. In the car rental agency you could easily use the same scripts for a RV rental company. Likewise, to make the soccer rules work for a different league, say under 19’s, only a couple scripts need adjustment and there are no side effects for doing so. In a traditional software approach you would have to change some deeply nested, deeply connected code in more places than one.
It’s important to embrace reality here. Rule engines in certain areas are popular. For example IFTTT is a very simple rule engine that is used all over the place. Also you have Tasker on Andriod which is largely a rule-engine. In the enterprise scene you have Drools, among many others, which is a popular open source package.
Our software, Nebri, is an Event Driven Platform which reacts to events with rules. It’s different than a pure Expert System (which can be implemented in Nebri) in that it doesn’t handle forward/backward chaining in an obvious way.
Rules themselves are certainly popular as a model of thinking and communicating. I was just in Berkeley where there was 5 different rules posted about parking, all on one sign. You can park here if it’s not the weekend, or the first of the month. You can’t park here if it’s during school, and so on. And of course, games that we play are filled with rules. But most notably is how we operate with other people, all day. Socially, there are plenty of rules in place: Don’t say X if person Y is in the room. Don’t have Uncle Tom to dinner if sister is also invited. Complain to a coworker and shutup around the Boss if he/she doesn’t like feedback.
It’s most natural to think in rules. Can we now bring this to development?
Here’s a nice SlideShare on the subject. Also, I enjoyed this article by a Drools user, and of course there’s a nice Wikipedia entry here. I didn’t go into the algorithms for rule execution, like RETE, because this article isn’t about implementation.
Here’s some popular home automation packages which use rules in some fashion. We would argue that rules would be THE way to automate your home almost...
We have a couple options for implementing a rules engine in Python: we can roll our own, or we use an existing one. Regarding the first option, it...
Rule-engines have a special advantage over their imperative counterpart. Lets get some footing with a quote from Martin Fowler: A rules engine is all...