The world of information technology has always faced lightning fast changes. A snap of your fingers and the environment around you undergoes some sort of change. And most of these changes are technology driven.
The changes that come about with growing market maturity phase in smoothly without causing much disruption. But the changes that are a result of technology advancement are sudden and at times disruptive. And these changes hit enterprise applications the most.
Applications that were once “state-of-the-art” developments suddenly become “legacy” applications. And when the application is custom developed for certain business requirements the problem is twofold. On one hand the application is perfectly fit for use and serves its purpose. But on the other, it no longer is compatible to the new environment. In this case, you cannot discard it nor can you use it. So then why not reengineer it?
Some say reengineering is technology and management science. We say it’s an art. It’s an art of modifying existing systems, processes, products, and services to make them more efficient and align them with latest advancements. Applications can be reengineered for adaptability issues, interoperability issues, and even usability issues. Even the most obsolete of systems can be reengineered to make them usable again.
So then how do you go about reengineering a legacy application?
Put up a Case for Application Reengineering
As an IT head, you might have felt the need to reengineer a certain application. You foresee this application as becoming obsolete in the coming years. But when you present your case to the board they go “when it’s not broken then why fix it”. They are not wrong on their end. They are merely looking at it from business angle. But here it won’t be a matter of ‘if’ but ‘when’. Waiting for an application to break down is like inviting doomsday. Your board can wait longer to reengineer the application and see the cost skyrocket. Or else, they can take preventive steps and reengineer the application at less cost.
Assess Your Current System
Once you get the green signal from your board, the next thing is to assess the system on hand. Identify the core problem that you would face in the future. Is it scalability that you are worried about or is it interoperability? Is hardware your problem or the operating environment? An IT architectural overhaul can also be a trigger for reengineering. Whatever the case may be, have a clear vision of your system’s existing state and its desired state. Also bear in mind the ROI that your reengineered application will have to deliver.
Your application when part of enterprise architecture interacts with other applications. There is an exchange of information that takes place to and fro from this application. These exchanges or automated conversations happen in a language so to speak. When you reengineer your application, you have to upgrade this language as well. If it’s an already obsolete or legacy application then even the language is going to be a legacy one. Upgrade this language to latest technologies.
User Interface Upgradation
When you reengineer your application, you might add a few features that make the application user friendly. But does your user interface support these features? Do you have a place on your application layout to display these features? If not, then you will have to incorporate these. This means you will have to redesign and upgrade your user interface as well for these applications.
Database Upgrade & Migration
Database is the foundation upon which your application rests. So if you are looking to reengineer your application then you have to consider your database as well. There is a good possibility that the reengineered application might not support the older version of database. So you might have to upgrade your database as well to higher version to support new technology of your application. You might even need to migrate your database. And then at times, you might not need to upgrade the database version or migrate it. A mere redesign of your database structure would do.
The whole purpose of application reengineering is to make sure that you are in tune with the latest technological advancements. So if your application itself is written in legacy programming language, then you better upgrade it. Let’s say you have an application written in ASP. The smart thing to do is to upgrade it to ASP.Net. But be careful. Technology upgrade should not render your custom developed features or functionalities non-executable. So do not forget to test run and simulate your processes through the application during reengineering phase.
You can put up a strong case for reengineering of your custom developed legacy applications. But what really matters is that once reengineered your application should deliver on ROI. That would be the best justification you can give for application reengineering.