Refactoring an Application – Beginning with Rules
We’ve all been there. You have a legacy application that has slowly morphed over time, showing increasing signs of complexity, and has finally hit the breaking point. Each subsequent change seems to take forever and half the time something else breaks in the process. Rewriting the application has been on your budgetary wish list each of the past five years, only to be dropped during the annual budget process. What else can you do?
Refactoring with a Rules Engine
Replacing your entire application during a big-bang implementation is not in the cards. Not only would the rewrite take forever, but by the time the application is completed it would already be obsolete. However, that’s not the only option. By pulling the business rules out of the existing application and moving those to a business rules engine you can take the first step in your refactoring exercise without having to rewrite your entire application.
Move the Rules that Change Most Frequently
There are certain rules in any application that change regularly. These rules are the ideal starting part to begin moving logic out of your legacy application. Business teams can then begin to take responsibility for the maintenance of the frequently changing rules and the development team can be programming the new API interface to the rules engine.
Build out the API’s in Legacy Code
The nice thing about the DECISIONS rule engine is that once the rules are created in DECISIONS with our graphical design tools we create the API’s that need to be called automatically. The endpoint that needs to be called is available to be used in the legacy application. Modifications in data structures can be handled at either end.
Document the Legacy Application API Code (and the Decisions Rules !!)
This goes without saying but you need to document the code at both ends. The comments need to explain what is going on with the application that isn’t immediately obvious. Put yourself in the mind of the reader. What do they need to know to figure out what is going on. Given that you are now connecting two different systems, it’s helpful to explain things from both ends.
To conclude, a rules engine is a great way to refactor an application without having to rip and replace the entire application. Logic can be slowly transitioned piece by piece without long delays. The benefits of a rules engine can then begin immediately without having to wait for an entire refactoring exercise to complete. You might even find that you don’t need to ditch your existing legacy application but simply convert it to a services-oriented architecture.
- How financial institutions can not just keep up with Joneses but outpace them
- What is Intelligent Process Automation (IPA) and why does it matter?
- Through earthquakes, unplanned outages, and grid failures: Keep your applications running
- Low-code vs. no-code: Which one do you need?
- What Exactly is a Business Rules Engine?
- How Can You Automate Quotes with a Business Rules Engine for Insurance?
- Use Automation and Custom Business Rules to Create Intelligent Asset Management
- Three Ways to Drive Process Automation for Insurance with a Business Rules Engine
- Where and How to Use Scoring Rules to Make Better Decisions in Process Automation
- Edge Cases Don’t Fit Your Workflow? Customize with a Business Rules Engine.