Building Business Rules Engines with Drools – Power to the SMEople
One of the most amazing things about working in software development is the ability to work in many different industries – especially if you’re a consultant. Most software development skills you learn while working within one industry are directly transferable to any number of other industries, companies, projects, and niches.
I’m speaking about topics like database design, design patterns, GUI layouts, event management, etc. Then, of course, there are topics specific to one particular industry, company, or project.
SME Meets IT, Knowledge Transfer Begins
This is where the Subject Matter Expert (SME) comes in. A SME will typically be very involved in the design stage of the project.
The SME has been working within the industry for a long period of time, knows the lingo, and understands the business logic behind the coding. The SME may have some understanding of software development, but this is not necessary for the project to succeed.
For many projects, unless the software developer has a great understanding of the business logic, completing a successful software application will be relatively difficult. The amount of time that needs to be spent on knowledge transfer will vary widely based on the project’s complexity.
Assuming that an agile approach is taken and one or more SMEs are available throughout the development phase of the project, knowledge transfer will continue during all stages of the project.
What If Complete Knowledge Transfer Is Not Feasible?
Depending on the industry and project, it may not be possible for an SME to deliver complete knowledge transfer.
For example, imagine if the SME is a physician with 25 years of experience, and you have 6 months to complete a project. Or, imagine the SME as a biologist with 40 years of experience – such a level of knowledge simply cannot be transferred in a realistic timeframe for software development projects.
But what if the knowledge area is dynamic?
Typically, software is released on a set schedule based on time or features. However, the business rules within some industries change much more frequently.
In many cases, it may not be feasible to release software as often as necessary to keep up with industry changes. Having the ability to externalize business rules within a business rules engine may make sense in such scenarios. The ability for a software project to be able to withstand change will go a long way toward assuring its ultimate long-term success.
When and Where Do Rules Engines Make Sense?
For many software projects, it is feasible for full knowledge transfer to take place, and for the business logic to be coded in a computer language such as C# or Java.
However, there is a subset of projects where the amount of understanding of a specific subject is so large, or the business rules are subject to so much change that it makes more sense for a non-programmer to have direct access to the business logic. This is the subject of this tutorial; with that in mind, let’s discuss Rules Engines in depth.
What Is a Business Rules Engine?
A rules engine is a tool for executing business rules. Business rules are composed of facts and conditional statements. Any “if-then” statement that appears in traditional business logic qualifies as a business rule.
For example: if an employee is out sick for more than 5 days in a row and does not have a doctor’s note, thenthey need to be written up. If a business associate has not been contacted for over 6 months and they have made no purchases during that time, then it may be time to send them a cordial email. If a patient has a high body temperature, vision problems, and there is a family history of glaucoma, then it might be time to request an additional MRI or other tests.
How Do SMEs Write Business Rules?
Instead of expecting an SME to learn Java, C#, or another programming language, IT will create a mini-language for him or her to express their business rules. The building blocks of these rules will consist of facts that can be queried for. Some examples of facts by industry/practice areas are:
- Human Resources: salary, position, manager, years with company
- Medical: temperature, blood pressure, current medication
- Financial: current stock price, 52-week highest/lowest price, P/E ratio, date of next earnings release
Essentially, the information necessary to make business decisions must be available to the SME in a streamlined fashion.
What Do These Rules Look Like?
For the remainder of this rules engine tutorial, I will be using Drools, an open-source Java based rules engine, which can be found at www.drools.org and is a JBoss project. In Drools, rules are written as Java code and have the following structure:
Import statements go here:
rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end
Drools and Working Memory
Drools employs a concept called Working Memory.
Application code will be responsible for loading appropriate facts into Working Memory so that SMEs can write rules that query these facts. Only facts relevant to application business logic should be loaded into Working Memory, in order to keep the rules engine running at top speed.
For example, if an application is determining whether to approve a customer for a loan, relevant facts would include salary, credit scores, and outstanding loans. Non-relevant facts would include day of the week or gender.
After Drools Working Memory has been loaded with rules and facts, the rules are evaluated according to the “then” part of their rule. If the “then” part evaluates to true, the “when” part of the rule will then be executed.
Typically, all rules are evaluated at once, although rules can be grouped together and evaluated on a per-group basis. The “then” part of the rule can change the contents of the Working Memory. When this occurs, Drools will reevaluate all rules to see if any rules now evaluate to true. If so, their “when” parts will be executed.
This recursive nature of rule evaluations can be a blessing or a curse – so rules need to be created with this architecture in mind.
The “If“ Side of a Drools Rule
In Drools, facts are represented by objects. The existence or non-existence of an object type can be queried for. Additionally, the object’s attributes can be queried as well.
Here are a few examples:
Determine if an employee earns more than 100,000.
Employee(salary > 100000)
Determine if a patient has cholesterol level of greater than 200 and is taking Lipitor.
Patient(cholesterol > 200, medications.contains(“lipitor”))
Determine if the price of a stock is within 1% of its yearly high.
Stock(price >= (yearHigh * .99))
When writing complex business logic, business rules can combine queries by using Boolean operators AND, OR, and NOT and nesting using parenthesis.
Determine if there is a manager making less than $75,000 or a director making less than $100,000.
Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)
Using Multiple Object Types
All of the examples so far have been based on a single object type, such as Employee or Patient. However, Drools allows queries to be based on multiple object types.
Determine if customer has a salary higher than $50,000 and has not filed for bankruptcy.
Customer(salary>50000) AND not exists Bankruptcy()