Optimization vs. Business Rules

on June 30, 2010

Optimization vs. Business Rules

Which is better: optimization or business rules? I’ve been asked this question over and over again through out my career. It’s like asking me to pick between a hammer or a screwdriver. Obviously it depends on the job at hand. That being said, I will do my best to respond.

What is Optimization?

First, we need to agree on the terminology. Optimization is an approach that finds the best solution to a problem. In order to do so, you will need to define what “best” means. This involved identifying facts and constraints and defining objective success criteria. Then you generate all possible solutions given those facts and constraints and evaluate the solutions against the objective to find the best solution.

Here is a very simple mortgage example:

Fact: The monthly mortgage payment is $3,000.
Constraint: The primary borrower’s income must be at least 3x greater than the monthly mortgage payment.
Objective: What is the lowest qualifying income?

An optimization engine executes the optimization model to “search” through all possible incomes and then identify the best one, which in case would be the lowest qualifying income ($9,000). Granted, this example doesn’t need an optimization model as it can be solved through mental math (basic algebra), but hopefully you get the idea. In reality, optimization models are you to solve more complex problems such as defining the optimal mortgage amount and terms that maximizes profitability for the bank while maximizing the likelihood that the applicant will accept the offer. Optimization models can also handle large search possibilities such as gate assignments for planes and airline crew scheduling.

What are Business Rules?

Business Rules is an approach that describes how you get to an end result. In our world, the end result is a decision, but decisions can also be a configuration, calculation, or set of values (similar to optimization). Business rules are often written as IF-THEN-ELSE statements. A rules engine “sequences” and executes the business rules.

Here is another simple mortgage example:

Rule 1: IF the total income of the primary borrower is less than 3x the monthly loan payment, THEN a guarantor is required.
Rule 2: IF the total income of the guarantor is less than 5x the monthly loan payment, THEN the application is denied.

Like with my optimization example, a rules engine isn’t necessary to execute these rules. A person can easily verify an application against these rules. However, in reality, business rules exist in the thousands or millions, depending on the use case. For example, regulations may force you to create many variations of the same rule, differing by geography and/or product line. With more number and complexity, a RETE-based (inference) rules engine will help executing the rules more efficiently.

How is Optimization Similar to Business Rules?

As I alluded to earlier, while these approaches seem to solve very different types of problems, there is an overlap: configuration. For example, let’s say you’re a manufacturer and you want to find the best way to configure your product, you could use either approach. Whether computers or trucks, you can use either approach to pick and fit mutually exclusive parts (ex. you can only have one motherboard in a PC and one type of tire on a truck). In fact, I have seen both optimization and business rules used in the following:

Processes: Some steps are inherently ordered while others are not. And some steps must be separated, especially in manufacturing, lest there be major consequences (ex. if certain chemicals interact, they would explode).
Offers: In life insurance and telecom, products and services have many options that require some intelligence to identify which are compatible and/or required.
Scheduling: I already mentioned scheduling for Airlines, but scheduling for sports teams and performers can also be challenging.

Therefore, the type of problem you are solving is not enough to dictate which approach to use. Instead, focus on the type of outcome that you and your stakeholders are comfortable with.

When to Use Optimization

When there are a lot of constraints and possible solutions are unknown, optimization is very efficient at finding the best solution (or letting you know when none exists). In addition, in cases where multiple “best” solutions exist, optimization can identify which solution has the most added value outside the success criteria.

Here’s an airline crew scheduling example:

Fact: You have 1,000 engineers to dispatch.
Constraints: Each engineer has specific working hours. Each job contract has a specific deadline. Each engineer must be assigned to a job that matches his/her credentials.
Objective: How to schedule engineers so that all of the jobs will be completed on-time?

In this example, there are a lot of constraints. Even though I’ve only listed 3, each one is really a summary of many. For example, working hours include time zone, holidays, vacations, etc. While in the rules community, the “Miss Manners” benchmark solves a similar problem with business rules (seat assignments for a dinner party), the rules are not easy to understand and focus on the mechanics of seat assignment rather than the description of the seating chart. Therefore, optimization is best suited to solving this problem.

When to Use Business Rules

When there are little to no constraints and possible solutions are known, business rules is great. While optimization will generate all possible solutions and then find the best one. Business rules, on the other hand, will lead you to one “pre-defined” solution. Therefore, business rules are best when you already know the “best’ solution or all solutions are, for the most part, equal in value. In other words, “good enough” is what you’re after. It’s no wonder that business rules are often used when automating decisions that were previously made manually. Business rules offer the flexibility to describe the decision logic step by step, one rule at a time. In addition, when businesses use a decision management platform like Sparkling Logic’s SMARTS™, they can also review execution traces that justify how the system got to the decision.

Here’s a telecom product and service offering example:

When a customer signs up, the telecom provider will put together a package based on what the customer wants. Some components are mandatory while others are optional. For example, long distance requires local service. However, long distance is an optional service. Some components are also mutually exclusive. For example, a customer can’t select both DSL or Fiber. They can only select one. Product managers can describe how the different components relate to each other. Business rules can then be used to capture product manager knowledge to appropriately configure a package for a customer.