Refactoring Business Decisions — Why is it important?

Refactoring business decisions have never been simple for enterprises. Here I have broken down the complex process of refactoring business decisions into simple steps to help you succeed in your mission. Most business decisions an organization makes are complex and need multi-level approval. This complexity gives more complex designs and implementation to automated solutions, making improvements a tough job. Improvements can be changes and adjustments to the business KPIs, system performance, reusability, maintainability, new behavior and requirement change, etc.

Market dynamics and demands, regulations, compliance, or change in systems, processes, and data might drive these calls for changes. Even when change is necessary, you may hesitate to proceed as the implications of these changes are still being determined. So how can you refactor the business decisions? Let’s get into the details.

How to de-risk refactoring a business decision?

As mentioned, Refactoring business decisions may look uncertain with the level of complexity that comes along. There are several benefits to performing refactoring. Here is what you must do to reduce the complexity.

1. Have data-driven test cases and scenarios along with the required data.
2. Have proper tooling that allows you to navigate downstream and downstream from processes to business decisions and necessary data and information.
3. Test your data against existing and new models (refactored models) automatically.
4. 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 the following:

• Your data for the quality test
• Good tooling
• Expert domain knowledge of the decisions

Refactoring Process:

The refactoring process has four significant steps. They are

Step 1: Setup Automated Tests

You need to set up a fully automated test scenario for two reasons.

1. You must comprehend the model and develop and prepare your test data. This forces you to learn the intricacies of how the model works.
2. It ensures you can run the tests with a single command or click as the model changes.

To make it more straightforward, you can run tests as you go, which will ensure the quality of your refactoring work.

You can create the test cases with input and expected outcomes for the decisions in an Excel file.

Then you can import the Excel file, automatically generate test cases, and run them using the CLI toolbox or within the authoring platform.

Step 2: Frame your business decision.

Using the decomposition technique and the decision graph, choose a complex decision and decompose it into smaller decision units.

For example, you can make a similar decision as shown below:

Without going through all the conditions, 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:

Step 3: Relocating the decision logic.

As we have defined the overall model, we must move the associated decision logic to their decisions. Business rules, statistical models, calculations, procedural logic, and so on can be used to inform decision logic.

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

Step 4: Debug and Test

At this stage, you can start running the automated test scenario for this new model, e.g., the decision graph showcasing the risk.

The pass/fail status of the tests will guide you through the model refactoring process. If you identify a gap, mark it with a breakpoint in the decision table or a decision unit in the decision graph so you can dive down into the details and figure out what is missing because you have the test that asserts the intended conclusion.

• 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 reasons.
• 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 and re-run the tests until they all pass.

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

Takeaway:

Refactoring is an excellent approach to ensure that complex judgments are broken down into simpler, more maintainable decision units. It also allows you to identify changes in the decision graph to replace one or more potentially rule-driven judgments with a more complex ML model.

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

Though refactoring business decisions is a complex and messy process that necessitates procedural and systematic thinking, it brings a lot of advantages for enterprises. With the right tools, you can reduce the risk levels and simplify the complex process. Although testing scenarios will still be required to ensure the quality of the new decisions, the automatic generation of test cases from an Excel document will considerably minimize the labor needed to construct test scenarios for more excellent quality coverage.