Now that we covered some basics about what not to do when writing rules, I would like to focus on what to do. The first aspect that comes to mind is the very basics of making decisions: the decision you make.
It is a common misconception that decision services make only one decision. There is of course a leading decision that sets a value to true, to a string or compute a numerical value. Examples are:
- approving a loan application
- validating an insurance claim
- flagging a payment transaction as fraudulent
A decision service typically makes that key decision, but it will often come with other sub-decisions. For example:
- risk assessment…
- best mortgage product…
- payment amount…
- likely type of fraud…
Making decisions or not
In my career, I have seen projects in many different industries. They applied to totally different types of decisions. I heard a few times, now and then, the desire to simplify the decision outcome. Just making a decision ‘in some cases’ is not enough though. Don’t assume that no decision equates to the opposite decision. This over-simplification is not a good design. Your decision services need to make decisions.
Business rules often flag a negative outcome, such as a decline decision, a suspicion of fraudulent activity, etc. It might be tempting to only respond when the adverse action occurs. If the person is not declined or referred, then he or she is approved. Why state it explicitly, when it is an obvious truth?
Your decision service, in such a design, would return “Declined” when the applicant is declined, and nothing when he or she is not.
There is no wrongdoing in flagging bad situations. I personally believe strongly in affirmatively stating the positive outcome as well. Your service eventually determines that your application is declined. It should respond that the application was approved as well, when applicable. It seems intuitive to focus on this negative outcome if that is what your decision service is designed to do. But it is also possible that the applicant could not be vetted due to lacking information.
Don’t let any doubt as to what your decision service decides.
Why is it useful?
You could assume that ‘no bad decision’ is equivalent to a ‘good decision’ of course. I find it brittle though. When an unexpected situation arises, assuming you reached a positive outcome can hurt your business. If your decision logic failed in the middle, don’t let it go unnoticed.
Don’t infer from this statement that I do not trust business rules. Clearly, business rules will faithfully reproduce the decision logic you authored. I am concerned about data changing over time. Established decision logic can change over time too, and often will.
Do not take for granted that all possible paths are covered. Today, your rules might check that all the mandatory pieces of information are provided. Let’s assume your decision service requires a new piece of data tomorrow. If the business analyst in charge forgets to check for it up front, you will reach a no decision when this data is missing. You will end up with many approved applications that were invalid to start with.
In simple terms, I highly recommend preparing for the unexpected, by not allowing it to happen without notice. Always state clearly the decision you reach. Add a rule to set the status to “Approved” if the application is not “Declined” or “Referred”. If and when you encounter these no decision situations, just update your decision logic accordingly. Plus, you significantly increase your chances to catch these problems at QA time. You don’t want to scramble after deployment of your decision logic into Production. That is the 101 rule about making decisions.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
