Rule engines are only a small (but tricky) part of decision management

Rule engine technology has a long history, by computer technology standards, that can be seen as the convergence of three advances, in 1) mathematics (theory of computation, developed by the likes of Turing, Post and Cburch), 2) cognitive psychology, which is concerned with modeling human cognition, and 3) artificial intelligence, which is concerned with heuristic problem solving.Roughly speaking, a rule engine can be seen as an interpreter that, given a set of if-then (production) rules, and a set of facts (application data), it checks the condition parts (if part) of all the rules, on all combinations of data; if an if-part is satisfied for a data tuple, the then part is executed on that tuple. Rule engines generally guarantee that all that can be 'inferred'/concluded from the rules and data, will be, regardless of how many 'scans' it takes. For example, if my ruleset (set of rules) contains the rules 'if credit score of loan applicant < 625 then applicant is ineligible', and another that says 'if loan applicant is ineligible then reject loan application', and my application data contains <loan_app_24, John_Doe> where John Doe has a credit score of 575, then the engine will, in a signle invocation, reject the loan application. This is called rule chaining. On the surface of it, rule engines sound awfully inefficient. In 1972, in his doctoral thesis, Dr. Charles Forgy invented a way of indexing the rules of a ruleset, and managing their executions (RETE algorithm) that made rule engine technology practical. Today, nearly all BRMS products use some version of the RETE algorithm, or one of the various enhancements that Dr. Forgy has been inventing since (RETE 2, RETE 3, and RETE NT).

While rule engines are the ... computation engine behind business rule management systems, they represent a very small part of the set of functionalities that you want from your BRMS to support your business in managing the business knowledge that underlies the decision logic.First, the rule languages typically consumed by 'raw' rule engine are a cross between logical notation and programming languages, and not readily digestible by a business person. Thus, you need functionality to: a) expose rules to business users and rule authors in a reader friendly format, and b) translate so expressed rules to the internal language consumed by rule engines. We will refer to these as domain-specific language (DSL) functionality.Second, as software artifacts, you need a host of functionalities to manage their lifecycle, including version control, testing, and quality control. General-purpose source code control systems do a poor job of managing the development lifecyle of business rules to the extent that they don't understand the internal structure of rules, and treat them simply as files.Finally, unlike Java, Node.js or SQL code, for example, which is meant to be consumed by IT or computers, business rules involve plenty of stakeholders, many of whom are not technical, and many of whom should have the authority to make changes to business rules. This requires far more sophisticated governance functionalities that is typical for purely technical artifacts.

There are plenty of good quality open source rule engines. Some open source tools have made (modest) forays in the DSL functionality space (see above). Some others have integrated some basic lifecycle management functionalities but not at the level of granularity that you want for business rules. Where open source tools fall (very) short is the rule governance functionalities, which is sine qua none to business rule ownership by business, one of the basic tenets of the business rules approach-- and decision management in particular.

For more on the history of rule engines, check, among others, chapter 6 of Agile Business Rule Development.

#DomainSpecificLanguages #RETEalgorithm #BRMSfunctionality #ruleengines