The legacy application dilemma.
The most common way to kick the can down the road is by modernizing the user interface without modernizing the database.
Another way to kick the can down the road is to modernize your database using surrogate logicals.
Reasons why the UI is chosen to be modernized before the database?
The boss says I want a modernized application. Most of all I want a new user interface.
It’s easier to just address specific issues as opposed to taking a larger more strategic approach.
Failure to recognize the implications of doing the UI first or the benefits of the MVC architecture.
Fear of risk
Strategic Argument
Doing the user interface first is counterproductive because you will be forced into converting the business logic from the legacy user interface to the modern browser language. That means new programming skills will be required and old programming skills will not. Secondly, it doesn’t get you any closer to a modern architecture MVC (Model View Controller).
In contrast, by moving the business logic from the legacy UI to trigger programs and taking advantage of DB2 constraints you will be making good use of existing RPG skills, as well as making the task of modernizing the UI simpler.
Surrogate logicals do not give you the full functionality of SQL.
Risk can be managed by running parallel databases. Simply add an after trigger to the original file, which will execute the new trigger program version of the same file (test library). Most importantly this allows for testing until satisfied.
Download a sample of a modernized 5 file application.
Check out a special offer to have one of your files modernized.