Business decisions are complex. Therefore, this inherent complexity generally leads automated solutions to even more complex designs and implementations for automated business decisions. The problem with this complexity is the fact that it will not lead to any improvements because it is very hard to change a complex solution (e.g. complex model) for any improvement. By improvements, we refer to any change and adjustment for

  • business KPI
  • system performance
  • reusability
  • maintainability
  • new behavior and requirement change
  • and so on…

These call for changes might be driven by market dynamics and demands, regulations and compliance, or change in systems, processes and data.

Even when change is necessary, you may hesitate to take the challenge as the implications of the changes are unknown.

So what’s the answer? To refactor the business decisions.

How to de-risk refactoring a business decision?

Refactoring may sound problematic and complex, brings uncertainty, and may look messy at the beginning. And you are correct!
What do you need to have in place to make it less risky so the outcome and benefits of the refactoring exercise outweigh the efforts?

  1. Having data-driven test cases and scenarios. Prepare your data for covering test cases.
  2. Having the proper tooling that allows you to
    1. navigate downstream and downstream from processes to business decisions and required data and information
    2. test your data against existing and new models (refactored models) automatically
    3. debug, step through and over different decision units, business rules, ML models, and processes

In the end, the success of your refactoring depends on the combination of:

  • data for quality test
  • proper tooling
  • domain knowledge of the decisions

So let's see what the refactoring process looks like.

Step 1: Setup Automated Tests

Setting up a fully automated test scenario is critical from two aspects.

  1. It requires you to understand the model and create and prepare your test data. This forces you to understand the details of how the model works.
  2. It ensures you can run the tests with a single command or a click as you change the model.

Making it easy for yourself to run tests as you progress will guarantee the quality of the outcome in your refactoring effort.

Test cases can be created by using an excel file with input and expected outcomes for the decisions.

Excel Image 2

Then you can import the excel and create test cases automatically and run them either using in CLI toolkit or within the authoring platform.

Step 2: Frame your business decision

Using the decomposition technique and with the help of the decision graph, start from a complex decision and decompose it into smaller decision units.

For example, you can look at a big, complex decision table like the one below:

Refactoring Driver risk Decision Table

Without going through all the conditions and expressions, and details of the decision, you need to start grouping the rules based on their impact and outcomes. Think of it as a logical, semantic grouping exercise, and you can see patterns emerge for two types of decisions:

  1. Risks associated with a vehicle type
  2. Risks related to the driver of the vehicle

Therefore, frame these relations into a decision graph as the one below:

Refactoring Decision Graph Driver Risk

Step 3: Relocating the decision logic

Now that the overall decision model is framed, we need to relocate the related decision logic to their decisions. The decision logic can be based on business rules, statistical models, calculations and procedural logic, and so on.

In this example, they are the business rules sitting behind each decision unit in your decision graph.

Book a Custom Demo

First or last name is too short





Step 4: Debug and Test

Now you can start running the automated tests scenario you already prepared against this new model e.g., the decision graph for determining the risk.

Tests will show pass and failure status, guiding you through the model refactoring. And if you find a gap, put a breakpoint in the decision table or at a decision unit in the decision graph and, you can drill down in detail and understand what is missing – This is possible just because you have the test that asserts the expected outcome.

Test Result

Select a decision unit in the graph, drill down to its decision logic (the decision table, natural language etc.) and ensure you have all the related rules, conditions and logic.

Select a decision unit, and find all its usages of if across your project to ensure you have used the decision unit in all expected decisioning scenarios.

Fill the gaps and missing decision logic, re-run the tests until they all pass.

To explore more about this project, visit FlexRule Resource Hub.

Conclusion

Refactoring is complex, messy, and very requires procedural and systematic thinking. But with having the proper tooling, you can de-risk it and make the process significantly easier.

Although you will still need to have testing scenarios to ensure the quality of the new decisions are not degraded, the automated building of the test cases from an Excel document will significantly reduce the efforts of building test scenarios for a better quality-coverage.

Refactoring is a great way to ensure you can split complex decisions into easier-to-understand and more maintainable decision units. It also enables you to discover opportunities to replace one or more decisions that are possibly rule-driven with some more sophisticated ML model in the decision graph.

For example, you can integrate an ML model into the decision graph to calculate the “driver risk” in the above model and combine it with the rule-driven decision for “vehicle type risk”.

Last updated February 2nd, 2023 at 09:12 am, Published January 19th, 2023 at 09:12 am