Making Decisions with Business Rules
Continuing my best practices series on rules authoring, I want to take a closer look at the decisions themselves.
Decision services execute business rules on input data to make decisions. A decision often includes a key decision that sets or computes a value. For example:
- A loan approval decision logs approved applications as “approved.”
- A payment fraud decision logs fraudulent transactions as “true.”
- A fee quote decision logs quotes with the calculated fee amount.
However, often other sub-decisions have to be made in order to make that key decision. For example:
- As part of the loan approval decision, the decision service must first do a risk assessment of the applicant.
- As part of the payment fraud decision, the decision service must first identify the likely type of fraud committed.
- As part of the fee calculation decision, the decision service must first select the “best fit” product for the quote.
For transparency, explainability, and compliance reasons, decision services often return these sub-decisions along with the key decision. Therefore, a “decision” is not just one decision but several related decisions which can get quite complex.
A “Non-Decision” is Not an Opposite Decision
In an effort to simplify decision-making, I have come across several projects in various industries where a decision is only made some of the time. Usually these cases are negative outcomes such as a decline decision or a fraudulent activity. With such a design, the decision service would only log “declined” for declined applications and do nothing for approved applications. The rationale behind that design is that approved applicants would just be the opposite of the declined applicants. Why go through the trouble of designing the obvious?
However, a non-decision isn’t necessarily the same as the opposite decision. For instance, what if your business rules miss a scenario in which an applicant should be declined? Nothing would be logged for this applicant and you would assume that this applicant is approved. Therefore, I recommend making decisions for every transaction. For example, log declined applications as “declined,” approved applications as “approved,” and applications that require additional information as “referred.” This way you can easily identify which scenarios aren’t being captured by your business rules since these applications would receive a non-decision.
Making Decisions for QA and Production
Creating rule sets for every decision outcome simplifies QA. Your rules will Every test case should have a decision which you can compare to the expected results. Both mismatches and non-decisions will help you pinpoint errors in your decision logic.
In addition, creating rule sets for every decision outcomes will also help you identify errors in production. Failed data pulls, field name changes, and other mishaps can prevent the business rules from firing and making a decision. Any non-decisions that arise will indicate that something’s broken or that something in your decision logic needs to be updated.
Continue reading my Rules Authoring Best Practices series:
- Rules Writing Pitfalls
- Decision Design
- Release Management
- QA Testing
- Decisions in Production
- Business Testing
- Object Model First
- Rules Requirements 101
- Data-Centric Approach to Rules Authoring
- Rules for Data Validation
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager