| Rule engine technology |
|
All organizations that work with a form of case consideration, where the decisions are based on a set of rules, should be interested in rule engine technology. If they are planning on making their case consideration more efficient or even automatic and at the same time control the quality of the decisions, de facto discrimination, use of rules and rule interpretation.To what extent the technology should be implemented is a question of cost/usefulness based on the number of cases that can be considered with and without rule engine technology, the amount of reduction you can achieve in case consideration time, wrong decisions etc. One can use this way of thinking and the concept that is defined to accomplish large implementation projects where all the rule considerations are gathered electronically in rule services.
ConceptsTo evaluate the suitability of a rule engine one should define a set of concepts and problems around the concept of rule engines A rule is a condition that has to be fulfilled for an event to happen or not happen. A rule on its own is a simple condition, but rules can be combined to a varying complexity. Rules within an area can be put into a tree structure, with the principal rules as the root and the decisions as branches and leafs. Decisions can also be based on following a sequence of rules until it branches, or it can be a set of rule branches weighted together as a final decision. If we stick to the domain of case consideration, and can say that a case consideration always leads to a form of decision, we can define two types of rules:
Procedure rules are usually simple, static and can be documented and implemented in a process. Decision rules are often complex and in many cases dynamic and partially based on assessment.
Why do we separate between procedure rules and decision rules, as there is just initially a grade difference? The challenge here is that a rule engine is a specialist tool optimized to handle large complex rule sets. It will involve an extra cost to use the rule engine if the complexity in the rule execution is not high enough. While other times you might be able to reduce the number of times you have to run decision rules in a procedure, not counting handling of complaints. This way the process might contain several procedure decisions. Adding these process decisions to the rule engine will involve bad utilization of the resources in relation to flexibility. Modern process modeling and implementation systems will yield the right flexibility in relation to process rules and is made for this purpose, but there are organizations that implement processes based on rule engine technology. A rule engine is an application that runs an evaluation on received data based on standard algorithms (i.e. RETE) Rules can be described in different ways, from written language to programming language, but they all use the "if" "then" "else" structure. In addition to support the standard algorithms, the different suppliers will continuously develop new functionality that will simplify rule implementation in addition to faster and more efficient rule execution. Some rule engines can just execute the rule forward ("forward chaining"), while others might also have the ability to run the rule backwards,i.e. you start with the decision and end up with seeing what criteria has to be fulfilled ("backward chaining"). Some rule engine suppliers also have tools to document, design and implement set of rules, in addition to version control tools for deploying rule packs to the different instances of the rule engine. In other cases the user will have to use standard tools to accomplish the same task. Some rule engines are expensive (license) while others are "free". By rule execution we mean the rules that are applicable for a data set that is active during the time the data set is created. A good example for this is when someone fills out a loan application online. The rule set is executed for each field in the application to check that the information is valid. To make this user-friendly, the rule execution cant take too long, meaning that the lookup will only run against larger systems with a fast response time. When all the fields are completed, the application will be managed directly or send to a final management. Batch oriented rule execution means that the rules for a data set are executed as one.For instance when making a decision after gathering information from many systems and sources and we have a complete data set. It is easy to imagine that it is desirable to combine these two methods. Depending on the amount of rule execution per time unit, it would be desirable to have different rule engine instances for the purposes. Decision tablesFor dynamic rules it is important to have support for decision tables, if not the rule sets can become unnecessary large and difficult to maintain. With decision tables it is also possible to create rule sets that can take assessment into consideration, even if it is an assessment based on quantified information. AssessmentIn some contexts we can say that decisions are assessment based. These decisions will to some extent be repeatable, consistent and objective in the case they are not quantified. If one in addition to this makes sure that the assessment is performed on a low level in the decision tree and that the resolution is based on a weighted evaluation of several assessment areas. This is a good basis for replacing assessment based rule execution with a more unbiased automatic decision. What to choose is more or less a political question. For most purposes, the majority of rule engines will be able to do the job, provided that you organize thereafter. For organizations that feel rule implementations should be handled by the regular systems development portfolio, a simpler rule engine would be the preferred solution instead of using a solution that is more suited for independent rule systems. By this we mean that it is the organizations responsibility to develop and offer a rule set as a service for the other systems. For very simple rule sets it might be enough just to collect the rules as rule objects, separating the business rules from the normal program flow. Generally it looks like Blaze Advisor and BizTalk Rule Engine are the prevailing commercial rule engine solutions in Norway, especially in the public authorities. Among the open source alternatives there are several, but this is more up to the current tool selection already available to the customer. Innovatec has used Blaze Advisor in most of the projects and is very satisfied with this rule engine.
|

