Refactoring an Application – Beginning with Rules

Blog: The Data Center

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.

If you would like to talk about your specific use case, or legacy application we would love to hear about. Please reach out to sales@decisions.com or request a demo.

The post Refactoring an Application – Beginning with Rules appeared first on Decisions Blog.