In Aug-2018 Prof. Robert Fourer gave a tutorial “Model-based Optimization“, in which he compares two essentially different approaches to modeling optimization problem: “model-based” vs. “method-based”. He is using a relatively complex “Balanced Assignment” problem to demonstrate his points. While Fourer’s tutorial deals with optimization, I believe the same arguments are directly related to Decision Modeling that so far mainly remains method-based. During DecisionCAMP-2018 we had interesting (and sometimes hot) discussions about these two approaches and in my closing remarks I described the major differences between them as follows:

• Model-based approach:
  • An analyst focuses only on modeling the problem of interest (WHAT)
  • The determination of a decision(s) is left to general-purpose, off-the-shelf decision engine (HOW)

• Method-based approach:
  • Along with modeling the problem (WHAT) an analyst also specifies HOW to determine a decision(s) in different situations
  • The decision engine executes a decision determination algorithm specified by an analyst.

In particular, I pointed out that one of the most typical complexities of decision modeling is exception handling when an decision analyst is trying to cover all possible situations using rules with multiple exceptions. While exceptions usually occur in less than 10% of real-world cases, exception handling takes more than 90% of decision modeling efforts. The necessity to represent multiple exceptions on top of other exceptions is frequently caused by the fact that decision modelers are trying to represent the existing (!) business logic. Such decisioning logic was defined before decisions were automated and when decision makers were doomed to follow some deterministic, frequently greedy algorithms. However, if we try to find out the actual reasons for exceptions, we may discover business rules that were hidden in minds of subject matter experts (Ron Ross calls them “tacit rules”). When it is practically impossible to cover all possible situations (various combinations of decision factors), decision modelers take shortcuts that lead to decisions which are far from optimal.

To demonstrate the limitations of the “method-based” approach, I took a simple problem “Vacation Days” that is frequently used to demonstrate decision modeling techniques. We need to calculate an employee’s vacation days following business rules based on different factors such as age and years of service. Fig. 1 shows a decision model that follows the method-based approach:

Figure 1. Vacation Days: Method-based Representation

This is one of 20 decision models submitted as solutions for the DMCommunity.org Jan-2016 Challenge, and they all used the “method-based” approach.

Note that the 3rd row in the above decision table “CalculateVacationDays” implements this rule: “Give extra 2 days only if you you haven’t already given extra 5 days“. Why extra 2 days cannot be combined with extra 5 days? Probably, the real reason for this rule was to limit a total number of vacation days while giving as many as possible extra days, which this employee is eligible to. Adding more extra days of eligibility conditions may create a real mess if we continue to use the method-based approach and will try to compare different eligibility criteria with each other.

Let’s reformulate this problem as it’s done in the new DMCommunity.org Nov-2018 Challenge:

      Every employee receives vacation days according to the following rules:

1. Every employee receives at least 22 vacation days.
2. Employees younger than 18 or at least 60 years, or employees with at least 30 years of service can receive extra 5 days.
3. Employees with at least 30 years of service and also employees of age 60 or more, can receive extra 3 days, on top of possible additional days already given
4. If an employee has at least 15 but less than 30 years of service, extra 2 days can be given. These 2 days can also be provided for employees of age 45 or more.
5. A college student is eligible to 1 extra vacation day.
6. If an employee is a veteran, 2 extra days can be given.
7. The total number of vacation days cannot exceed 29.

Now rule 7 explicitly specifies a maximum for the total vacation days, but many other combinations of extra days could take us above the 29 limit. Of course, we still could use a method-based approach with three algorithmic steps:

1. Calculate an employee’s eligibility to all types of vacation days benefits
2. Apply all eligible criteria to calculate the total number of vacation days
3. If this number exceeds 29, assign 29 to the total number of vacation days.

However, it would mean that we are allowed to subtract days from some eligible days (without even knowing from which one) and to give only a partial number of eligible days. What if it’s not allowed? Consider a benefits management system with hundreds of possible benefit types (similar to vacation days) when some benefit types are mutually exclusive. The benefits could have associated values but they could not be given “partially” (everything or nothing). The method-based approach would not work in these cases, especially if you want to maximize the total value of all given benefits while providing some limitations (such as a percent of the total value).

How would a model-based approach help? We may reformulate the vacation days problem as in Fig. 2:

Figure 2. Vacation Days: Model-Based Representation

In this model, all eligibility rules still can be represented using business-friendly decision tables such as 3 tables on the right of Fig. 1. However, we don’t need any more a summary table “CalculateVacationDays” with inter-rules relationships. Instead, we introduced unknown decision variables Xt  to define if an employee will receive vacation days of the type “t” or not. These variables are defined for every vacation days type including basic. Using these variables we can define the objective as a sum of all vacation days multiplied by these proper Xt variable. We also can limit this sum by some number MAX_VACATION_DAYS, e.g. 29. Then we can ask a decision engine to maximize this sum.

If we want to allow using partial numbers of vacation days for different types, instead of using  as integers, we may define them as integer variables, which take values from 0 to a number of days for the type t.

This approach not only eliminates all rules about relationships between different types of vacation days. It also replaces a one “greedy” path to solution with an ability to find a true optimal solution.

I understand that the use of mathematical notation may scare business users, and we need to find a user-friendly way to represent this model using a particular decision modeling tool.  However, at least we should make sure that a business user is aware that our decision engines could handle this and much more complex modeling approaches (constraint and linear engines successfully do it for decades!). I submitted two different representations of this model in response to the Nov-2018 Challenge. They both use OpenRules and JSR-331: the first solution has the business part defined in Excel and the optimization part defined in Java; the second solution is an attempt to define both parts directly in Excel (without Java).

To show advantages of the model-based decision modeling for more complex problems, let’s consider define a new decision model for the “Flight Rebooking” problem:

A flight was cancelled and we need to re-book passengers to other flights considering their frequent flyer status, miles, and seat availability. How the re-booking logic can be represented in an executable decision model?

DMCommunity.org published 5 different decision models for this problem. They all (including my decision model) use a method-based approach that with small variations follow this algorithm:

Figure 3. Flight Rebooking: Method-Based Representation

This is certainly a “greedy” algorithm (or a heuristic) that will produce a decision, but we would never know if this decision is the optimal one. So, it unnecessary could leave some passengers very upset.

Fig. 4 shows an alternative, model-based decision model:

Figure 4. Flight Rebooking: Model-Based Representation

In this model we introduced new decision variables “Passenger Penalty For Delayed Hour” one for each passenger, and we want to minimize the total penalties while assigning passengers to flights.

These penalties could be calculated for each passenger (independently to which flight this passenger is assigned) using this decision table:

Figure 5. Flight Rebooking: Calculate Passenger Penalty For Delayed Hour

We can use these variables to specify our minimization objective as a sum of all products   for all passengers and all flights. Our decision model is supposed to minimize this objective subject to two constraints:

1. Each passenger can be assigned to no more than 1 flight
2. A number of passengers assigned to the same flight cannot exceed the flight capacity.

The advantages of this model are obvious:

• We do not have to implement the above greedy algorithm in Fig. 3
• Instead of one possible decision, we will find an optimal decision
• A business analyst will be able to adjust penalties in the decision table in Fig. 5 and the same model will produce different optimal decisions.

Of course, to implement this decision model we need a much more sophisticated decision engine that is usually used by the majority of rule engines including those that support DMN. I implemented this decision model using a combination of OpenRules and JSR-331: I will publish its description soon.

To finish this initial comparison of Model-based and Method-based approaches to decision modeling, I’d like to share several examples from these popular business domains:

Figure 6. Model-based Decision Modeling in Loan Origination and Insurance Domains

Certainly, the model-based approach will make decision modeling in these domains much more powerful, and may address problems which previously were out of reach for traditional rule engines.

In conclusion, I want to stress that there are many possible implementations for the model-based approach: I plan to describe some of them in another article. This is work in progress that requires additional research and practical implementation for various decision modeling problems. Hopefully, more people will join these efforts.