What Future for the Legacy Applications?
The future of the legacy applications between preservation and disposal
Intro
In the era of maximum technology growth the legacy applications maintain their position and role.
Many companies spent their time in and money in during the 80s and 90s to realize big legacy applications that were be revealed the right choice to stay on a step with the growth.
Today these same companies ask himself if it is the right way to pursue or if it is the time to go to the new.
In this story I’ll try to analyze some ways to transform legacy applications.
Let’s go!
Approaches
Many of the legacy applications run on mainframe and has a business logic implemented that is running by 20 or more years.
For the companies, when the cost of managing increases, is very hard to choose about the future of the applications.
It is possible, in a base of my experience, to attack the legacy applications on one of these three levels:
- View: replacing the views with new ones and maintaining the core of the code and the data
- Business: replacing the views and refactoring the business logic, but maintaining the structure of data
- Data: replacing the views, the business logic and the data
The possible approaches to renew the legacy applications in the base of the attack layer can be:
- Preservation of logic
- Refactoring
- Migration
These ways to proceed can have different costs and impacts by the applications and are recommended a good assessment before to start to follow a way.
Now I’ll try to explain these approaches in detail.
Preservation of logic
The first approach is dictated by the idea to maintain most of the business logic contained in the legacy application.
Often is common to think that the current implementation is stable and bug free so is deciding to maintain the database and the layer of the software that contains the business logic.
This way to proceed provides to expose the business logic as currently implemented through web services (for example with SOAP or REST services) and after creating a new layer of front- end to dismiss the old model of visualization.
The cost of refactoring the business layer and the data layer is cheap because the only develop to do will be the exposition on web services of the current code: individuates the code to expose and realizes the web services.
On the other hand the costs of realization of the view may be high because may be difficult to orchestrate from the new front-end the old functions that will be exposed without any modifies.
The exposition of the as-is functions permits to preserve most of the code, but complicate the development activities of the front-end: save costs on the legacy application, but spend more on view.
The plus of this approach is that the development and the go-live of the new application can be parallel with the utilization of the old legacy application.
Refactoring
The most common approach is to realize a new web application maintaining the data layer.
It is easy to think to a new front-end and is quite easy to realize a new business layer (if you have the functional specification) but in many cases it is hard to think and migrate the database to a new model.
In the design phase it is possible to decide to create a business layer that accesses directly to the data layer or to create an API layer between the DB and the business layer to decouple the two layer and offer a web access (and where is possible also asynchronous) to the persisted information.
Optionally is possible to realize a layer of API services to permit the access to the data directly by the web application decoupling the old technology of the data base with the new technology of the higher layers.
The costs of this approach are too high: it is required to create a new front-end, to refactor and realize the new business layer and if it is appropriate a new API layer.
A benefit of this approach may be the radical change of the technology and the technology of the application.
Providing a deep assessment on the legacy application it will be possible to investigate the presence of defects in the architecture or bugs in the functional processes to avoid it on the new application.
Data migration
This last approach is thought to renew all layers of the legacy application.
The companies that follow this way to renew the legacy application are moved by reasons as elevate management costs, an internal IT decision that force to uses a new technology, difficulties in recruiting people that know the programming language of the legacy application and/or many others motivations.
The legacy applications in many cases were been developed many years ago and were remain stable for years and years, but the time that was gone has revealed the leaks and the limits that are possible to fix only with a complete renewing of the software stack.
The decision to migrate the full stack of the legacy application to a new architecture may be start with the definition of a new data model where will be migrating the current database. The next step will may be to design the architecture of the new business layer for example to realize an API that can be invoked by the new front-end and the last-but-not-least is the design and the realization of the new front-end.
This approach requires to the companies to have on-board a lot of specific professional figures with a lot of specific skills, for example:
- Database Architect: to recommend the right Database technology, advise the adoption of relational rather than no-relational and design the data model of the entities;
- Back-end Architect: to propose the programming language to adopt, to design the architecture of the back-end and to organize the patterns to use;
- Front-end Architect: strictly connected with the back-end Architect but for the front-end technologies;
- UX Designer: to design the new User Experience to mount on top of the new web application;
- DevOps Architect: to design the new work flow of the operations about the automation of tests, packages creation and software deploying;
- Front-end and back-end developers: the real workforce of every project that transforms the ideas in reality;
- More others: finally other resources are needed for the migration like Test Architect, Security Expert, Infrastructure and Network Expert and many others.
The presence and the number of these resources can change based on the size of the project.
Conclusion
The euphoria of the moment will be run out when anyone will pronounce this question:
Is the legacy application too old that we need to dismiss?
Much of the legacy applications are too big and so will find out that the renewal costs are greater than the management costs and often will decide to maintain the application as-is.
The step of renewal, that it will may be partial or total, has a cost and an impact. Before to do this big step it is strongly recommended to do a deep assessment to define the costs and to hypothesize the benefits of the new application.
When we will have all these information can be posted on the scale plate and see where the scale pend, but until this moment the renewal of the application will remain only an idea.
Thank you for your time!
