When I learned that the famous Prof. Raymond Smullyan passed away this February at the age of 97, I felt grateful to the man whose books and puzzles my friends and I enjoyed reading as young programmers many years ago. Later on we shared them with our children. I wanted somehow to mark this event and decided to buy his book “The Chess Mysteries of Sherlock Holmes” to read on vacation. Ten days ago I started to read the book during my flight from Newark to Jamaica and… haven’t even noticed as we landed.

Besides creating intriguing problems, Prof. Smullyan was a master of great presentations. For example, in this book he mimics Arthur Conan Doyle. Holmes and Watson enter their local chess club where they witnessed the following position of a just ended chess game:

Sherlock Holmes considers the position momentarily, then announces which side of the board White played from (top or bottom of the board), which astonishes Dr. Watson.

Holmes and Watson had a really enjoyable analysis of this position but it is too long to repeat here (you may Look Inside the book to read it). I will only suggest how you can solve the puzzle. You don’t have to be a chess expert to get it – just be aware of legal chess moves. You may notice that the Black king is checkmated by the White bishop.  In order to know which side is White, you must ask yourself what White’s last move was.  And in order to answer that question correctly, you must first determine what Black’s last move was before White delivered mate.  Smullyan calls this type of reverse engineering “retrograde analysis” (or briefly “retro-analysis“) where you think backward from the position, rather than forward.

The retro-analysis forced me to think about business decision modeling and backward chaining when we know the results of already made decisions but want to understand what business logic led decision makers (or a rule engine) to these decisions. Before switching to decision modeling, I still want to share with you another chess problem that requires a similar retro-analysis and that may drive you crazy:

The White king has been knocked off the board.
On which square should it be replaced?

Try to solve it, but if you think it is impossible, look at the solution at the end of this post.

Back to decision modeling. Various DMN-like decision modelers (including OpenRules) usually help you to identify all of the decision inputs, including data, business knowledge and results of other decisions. They also help you to focus on the decisions rather than the rules, identify dependencies throughout enterprise decisioning processes, and finally they can execute your decision model against specific input data to come up with a particular decision. Good decision modelers also help you to understand how they arrived at a decision in a way doing an automatic “retro-analysis”!

In real-world of business applications, business people want to modify the business logic of their decision making software to come up with different decisions. Consider two typical examples.

1. Insurance Premium Calculation. A top-level management of an insurance company may ask their business analytics team to change premium calculation logic in such a way that will make their products more attractive to people with certain demographic and income level requirements. The problem can be translated to this question: what changes should we make in our discount/surcharge rules to minimize an insurance premium for these customers by 20%?
2. Loan Origination. A bank may decide to minimize a number of rejected loan applications. For example, instead of rejecting a 50K educational loan, we may recommend a borrower to increase the loan term while slightly decreasing the loan amount. The problem can be translated to this question: what changes in the loan term, amount, and other loan conditions should be made to allow us to accept more loan applications without putting the bank in trouble down on the road?

In both situations, we have certain requirements to the final decisions (we know the final position) and we need to work backward from the position to identify business rules that may lead us to such decisions. Both situations give us examples of retro-analysis, don’t they?

To add to the challenges, we should consider the situations when a decision model can lead us not to one but to multiple possible decisions. In this case, we also should consider how to select an optimal decision among multiple alternative decisions. The optimal decision will be the one that minimizes a certain business objective. In the case, when we know the desired decision the optimal one will be a decision that is the closest to the desired one.

Without calling it retro-analysis, I’ve already described in my previous posts how we can use OpenRules Solver and What-If Analyzer to support the related problems. You may look at some of them with a new “retrograde” perspective:

• Decision “Determine a Killer of Aunt Agatha”: here we knew that someone in Dreadsbury Mansion killed Aunt Agatha and several related facts about suspects. We applied retro-analysis to find a killer and even proved that she acted alone.
• “Monkey Business” Analyzed: here we knew about eating and resting habits of four monkeys and needed to figure out what kind of fruit each monkey ate, and where they rested. Applying What-If Analyser (retro-analysis) we had shown that the problem has 69 different solutions. All other decision modelers were able to find one solution only. We demonstrated how to activate an additional constraint “Monkey Use Different Resting Places” to come up with a unique solution.
• Decision Models: Finding Alternative and Optimal Decisions: this post describes how to deal with the above loan origination scenario.

You also may want to read an old (1994) but very interesting article by Philip Best “To Know The Future You Must First Know The Past” from which I borrowed the above chess problem with a knocked-off White king. By the way, below is its step-by-step solution:

1

2

3

4

In this position the White king was knocked off the board!