5 steps to decision-centric legacy modernization

Last week I emphasized four key facts about legacy modernization. To move forward you need to find the legacy code that represents business decisions such as a pricing engine (what price is this product for this customer), eligibility logic (is this customer eligible for this offer or service), approval rules (can this claim be auto-approved) and replace those parts of the application with Decision Services.This week I am going to walk through the 5 steps involved in this kind of decision-centric legacy modernization (and don’t forget this recording of the webinar on legacy modernization we did with our partner TechBlue).

1. Analyze the code to find and isolate the decisions.
   The first step is to find the pieces of legacy code that make decisions. These will have the most change requests, the most complaints and often the most complexity to the logic in the current system. Most projects will find they need to do some code rework to isolate these decisions in their own component (few legacy systems are well designed in terms of services or components).
2. Model these decisions so you understand them.
   Using established decision modeling techniques and the standard notation for decision models (Decision Model and Notation) you can develop a model of this decision-making. The top-level decisions, the ones represented by these components, are broken down to understand the sub-decisions, the decisions that must be made first. The input data required to make these decisions is identified, often using the data passed around in the legacy application as a guide. As the decision model is developed the knowledge sources that describe HOW these decisions and sub-decisions should be made are identified. These can be policies, regulations or other requirements that constrain or describe the decision-making. The end result is a model of the decision making that is precise and that shows what information and knowledge is required. There’s more on this in our white paper on Decision Modeling with DMN.
3. Work out the rules for these decisions and document them in a business rules management system.
   You can analyze the code to find rules but starting with the original policies/regulations is often much more effective as code analysis gives you VERY technical rules. Policies and regulations identified in your decision modeling should be used first where possible. The code can be used to see what changes were made in the system relative to the original intent – some will be wrong but others will be practical adaptions of the original policy to address holes and contradictions in the original requirements. Each piece of the decision model can be considered in turn, focusing analysis and rule writing on a specific part of the decision-making.
   For those pieces of the decision model where the only source is the code it will need to be reverse engineered. This generally results in very technical rules that should be “walked back” to find more business-oriented rules. The decision model acts as a framework for this, making it easier both to assign reverse engineered rules to the right part of the decision and to make sure the final rule makes business sense.
4. Use the BRMS to redeploy the rules as a decision service that the legacy application can access.
   The behavior of the decision service can be tested against the behavior of the isolated decision-making logic in the legacy application. Any test case variations will need to be investigated although experience suggests that you are much more likely to find that your legacy code is working wrong than to find that the rules you wrote are wrong! Regardless you need to be able to document and explain variations.
5. Retire the replaced code
   This means that most of the code in the legacy application has been left untouched. It still runs as it did before, except that now it calls the decision service you deployed instead of the legacy code.

Over time you might revisit this and replace the non-decisioning pieces too. If you do you will want to replace the monolithic legacy application–containing data management, user interfaces, decision logic, and work flow in one block of code – so that each element is managed by an appropriate environment. We have already replaced the decision logic with business rules managed in a BRMS and we should replace data management logic with a model-driven ETL tool, workflow logic with a process model in a BPMS etc.

Don’t forget this recording of the webinar on legacy modernization we did with our partner TechBlue.