RIDDLE ME THIS!
Q: What is a low tech programming solution that is hard to implement?
A: I hate riddles, so I’ll give you the answer right away: A RULE ENGINE.
Q: What’s so special about a rule engine?
A: It’s simple. It’s usually a list of some sorts that can be examined by software to make a decision, but the beauty of it is that a dizzying array of decisions can be automated using this simple device. You’re #CuriousAboutData, so read on!
Let’s look at couple of examples:
One of BitWise’s customers provides loans. Loan origination is a complicated business with many rules imposed by different entities. All these rules have to be combined to determine if a particular loan can be considered “good” or “bad”.
What is a rule? Technically speaking, it’s a statement that evaluates as true/false, so it’s a proposition. It’s truth value depends on data, so it can be often formulated as an SQL statement. Evaluation is simple and can be tested and verified for accuracy; at the same time, these rules can be combined to produce the most sophisticated classification mechanism imaginable.
The team at BitWise went through dozens of iterations tweaking these rules. Because each rule is an atomic operation and therefore easy to verify, it was a painless process. In some cases we will also add a Graphical User Interface (GUI) for business users to interact with the rule engine directly. We don’t like dependencies in code, so why should we have them in business relationships?
If you have a server or two, you can just check on them now and then, but what if you have a 100 servers? Or 200? It becomes a bit more complicated. This was an interesting project, because BitWise played two roles — business analysts (since we were supplying the domain knowledge on what to monitor and how to determine if a server needs attention or not) — and rule engine developers.
We’re not going to get into details about how the actual server data was collected, but eventually it made its way to a central database. The BitWise rule engine would take the latest metrics from there and iterate over a set of rules that gave a score to each server. These scores would be displayed in a traffic-light performance dashboard — along with a score for each server — giving operations an easy tool for troubleshooting.
One of the goals of this system was for rules to be data driven, so that an operator could change requirements on the fly. For example, memory utilization was considered normal when under 80%, but if for some reason we wanted to change that rule, it would be simply a matter of updating the number ‘80’ in a database table.
Easy? Kind of. A lot of thinking went into the design of various rule types, workflow, rule weighing, etc, but implementing it was simple. At BitWise, that’s how we like to work. Think ahead of time, so that actual work is minimal and meets all requirements.
We like people, so feel free to call or write. Humans only.