VOLO Tech Talks - Legacy Applications Modernization
Hello and welcome everyone to today's webinar discussion, which is on Legacy Applications Modernization. I am Mariam from VOLO's Business Development and Marketing team and it's my real pleasure to be your moderator today. Thank you all for joining us wherever we find you. I am delighted to say that this webinar is brought to you by VOLO experts in their respective spheres who have extensive experience in modernizing legacy applications. As a brief introduction, VOLO is a custom software development company that has been in this business for over 17 years with a team of 300 specialists. Now let's give a warm welcome to our speakers, experts, who are going to provide us with insights to support your business.
It's my pleasure to introduce you to Nune Darbinyan, a seasoned software engineer with more than 10 years of experience in custom software development and legacy app modernization. I know that Nune has consulted numerous companies on their digital transformation journeys helping them select the best approaches for modernizing their apps and has successfully led multiple projects from concept to completion. Hello Nune. Hi Mariam. Hi everyone. It's nice to be here, thank you. And our second expert on this topic is Ani Mehrabyan. Ani is a senior software engineer with more than
eight years of experience in software development, five of which specifically doing legacy revival projects. Hello Ani. Thank you, Mariam. Hi everyone. Thank you for joining, girls. I'm sure there is a wealth of knowledge to share with us today. Now let's take a look at the agenda of our discussion I will start with a brief overview of describing legacy applications common characteristics, the challenges that businesses face with legacy apps and the benefits of modernizing them. Then, we will discuss the application modernization processes exploring the common methods for modernization and the approaches taken specifically by VOLO. We will also give examples
from various projects that we have had over the years to bring home the ideas that we discussed. Please, keep in mind that at the end of the session we will have time for your questions, so you can participate as well and ask all your burning questions in our chat room and by the way you can find that in the lower corner of your screen. Okay. And as a reminder, this webinar is being recorded and you can access it in your mailbox within a couple of hours once it is over. So before we really get into it let's first define what we mean bylegacy applications. Nune, the stage is yours. Thank you. Okay, let's start. So many people automatically assume that legacy
software means a solution that's been written a long time ago in a language that's no longer considered modern. However, I really want to point out that neither the programming language nor the age of the application really determine whether it's outdated. In other words, you can have a solution that's written in, let's say, not so modern technology, but it doesn't automatically mean that it's legacy. It might be perfectly fine. It all depends on how well it has been maintained. So, in fact, legacy can be considered any software, technology or system, that blocks or slows down your business processes and makes them difficult to adapt to your market dynamics.
Nune, I wanted to also add, that, as someone from the business development, there's some main concerns we have heard from business owners with regard to their existing legacy applications, and while the situation differs from business to business, most of these can be grouped into several categories, right? Yeah, that's right. Let's look at these categories. So, let's look at this list of main problems that legacy applications pose for your business. Okay, first one. I want to mention the no flexibility and scalability issue. This means that it's not possible to integrate or almost not possible your legacy solution with today's newest technologies. It can be cloud computing, API usage, any third-party business application.
Next item. It's high maintenance cost. This is a big one for many companies and companies with legacy systems have to pay extra for the upkeep of the outdated technology. And new development is often very expensive, because things just can't be done quickly.
Another big issue - security threats. If your system is outdated you won't be able to schedule these constant updates or fixes. This eventually results in data protection issues. another characteristic of Legacy software is its massive code base this big big code base in such cases there is this unwanted chain of reaction the constant functionality breakages you touch an area of code and it usually affects the others and causes unexpected problems next one shortage of professionals we should not ignore this there are fewer and fewer professionals who can and want to work with outdated software this is very natural and most of the developers really prefer to work with modern Technologies and that's why they constantly upgrade their skills and finally low performance Legacy applications tend to work slower I think we all have noticed that and it creates a bottleneck in your business operations today everyone leaves a fast-paced life and the last thing that anyone wants to face is something that slows them down So eventually of course this ends in frustration of end users so in order to mitigate all these mentioned challenges companies make the Strategic decision to modernize their outdated systems so what exactly does it mean to modernize an application Legacy application modernization aligns the existing software with modern business requirements with using new technologies this definition sounds quite simple but in reality what happens underneath is quite complicated first to come to this decision businesses must understand why modernization is so crucial so in our world and especially the world of tech it's constant rapidly Changing State software systems supposed companies in navigating this ever-changing world and there is a growing Rift between increasing the business demands yes and the organization's ability to keep it up and as you see from the picture there is this Gap this acceleration Gap uh organizations need to become adaptable and close this Gap let's say as soon as possible to compete with this rapidly changing world but adaptability is hard when your existing system is legacy so if a company doesn't update its software promptly it loses more in the long term moreover the longer the delay the more expensive the upgrade will be based on our own experience in Volo with our clients we have concluded that after a few years of waiting just a few years of waiting the costs of replacing or upgrading the updated system increases exponentially so in very basic high level terms let's just sum up companies modernized to deal with issues such as data loss lower performance technical limitations and high maintenance costs so at this point we understand why companies modernize now let's see what are the possible approaches to do it let's look here so here we have seven approaches this approaches are presented in order of complexity and impact let's quickly go through each of them first let's start with low risk processes this first free one they are localized changes and improvements to the existing system so first one encapsulation that's when we leverage and extend the application features when by encapsulating its data and functions mostly making them available through apis next one rehost that's when we redeploy the application component to another infrastructure it can be physical virtual Cloud doesn't really matter the important thing is we don't modify the code next one is re-platform that's when we migrate to a new runtime platform we make minimal changes to the code but we don't touch the code structure so this free they are relatively simpler and of course their impact will be lower let's go to the next next session so it's medium risk processes so they are gradual Replacements or refurbishments let's say first one refactor that's the word we often hear and we often use uh that's when we restructure and optimize the existing code although not its external Behavior we just do it to remove tactical depth and improve our non-functional attributes and a bit more serious which is re-architecting that's when we materially alter the code and shift it to a new application architecture and at the same time we exploit new and better capabilities so these two as we see their impact is growing with the risk and the last one is our high risk processes these are um complete Transformations and even replacements so rebuild that's when we redesign or rewrite the application component from scratch and we Preserve of course the scope and specifications of the application and the last one is the replacement that's when we eliminate the former application let's say completely and we replace it and during this replacement we consider new requirements and needs so we see this approaches so a question comes how we decide which approach is suitable for a certain case for that we have a decision metrics that can help us let's have a look at it so as we see from this metrics the sections where the business requirements correspondence and the application complexity are on different size the light blue one and the orange one that's the places where we have to make critical decisions either replace or do nothing for other two cases those are our general projections that we just discussed of course this Matrix serves as a helpful guide in general and as a spoiler I want to say that in our experience in Volo we have used all of these approaches in multiple projects but before that before diving into that let's see what is our specific approach that we have developed over the years and how we make decisions when dealing with this Legacy let's go step by step at our approach just I want to mention that of course the approach differs from case to Case and we adjust it based on the top problem with which the client comes to us so the first step at this step the tech team conducts several discussions with the client we understand the product the client need next a thorough assessment of current infrastructure is done as we want to understand how the outstated system will affect the company's business customer experience we mainly focus on long-term benefits here the team technically investigates the system we evaluate current condition all the dependencies of course and any issues that impact the quality the most after this step it may be decided that it's not beneficial to do modernization at all that's to say to retire the application uh considering the costs of benefit after the analyze I want to mention that it's not a bad thing it happens it's a common case sometimes it's perfectly fine to leave things as they are rather than to do some unplanned yes and without measuring the risks some actions if after this point we decide to proceed with the modernization the team suggests approaches and comes up with most Optimal Solutions so we present it to the client we create the plan and of course prioritize the actions as a result we have a road map that's created with timelines with actions of our modernization um just a note here that if we are also involved in active development at the product so not only the Legacy part we do the continuous modernization approach meaning that alongside with the continuous development of new features we gradually manage the technical depth and we prevent it from becoming the business pain and eventually a legacy so that's also an approach yeah and as we talked about uh specifically wallows approach I'd like to announce that for the participants for this webinar we have good news and if you have a software application and there are some concerns related to the performance and you are just looking for your business acceleration we are more than happy to schedule a free consultation session and give you our feedback and for that you can click on the link shared on the screen and pick a time that works best for you uh now that we have a time uh that we've covered uh the theory uh or and uh I think it's a it's a perfect time to talk about some common cases that affect many companies regardless of the industries they operate in okay without further Ado let's get into it um many of our clients didn't come to us exactly for legacy modernization they came to us seeking solutions to various problems they were experiencing with their software and as none already told you guys the first thing we do is set up Discovery sessions to analyze our clients projects and understand what challenges we are going to face in the process and often enough we find that they have a legacy system at hand that needs to be dealt with in a way that goes hand in hand with their business needs and strategy the product cases I'm about to cover come from various Industries like Insurance trading governance Etc at the time when they approached us their software was at least five years old and the technology is the that they had used were pretty outdated but fortunately for us and them not too old and so let's go let's go over these common difficulties and challenges that companies experience uh very often the development teams this can be both in-house and outsourced teams that were working on their systems either no longer worked for them or there were only a handful of people left which means no point of contact existed to cooperate during code changes because of this it took us considerable time to dive into the codes and understand all the code relations without having any help from from an Insider and you can understand how this affects the length of the process it took more time and another common problem was missing documentations for the application behavior of course meaning there was no possible way to check whether a change in the functionality would affect the entire system in other words you fix one issue and end up causing 10 other issues as a result uh to deal with these type of issues we included business analysts together with the dev team in the Intensive Discovery sessions with clients to go over their system features by feature and together with them Define the acceptance criteria by investigating the code and eventually develop documenting it ourselves yeah and the last but not least we had the cases when there were no acclimation tests on the system when we don't have affirmation tests it creates difficulties in system consistency and so we had our automation QA Engineers to write automation tests based on the application criteria which would run before and after the modernization feature by feature to make sure we have the same results as before and now let's talk about the exact actions we took with a few technical descriptions and explain what issues they solved yeah the first we will talk about constant breakages we re-architected some nested services from the monolithic applications into microservices with separate databases and some of the services were fully rebuilt that way the failure of the service did not cause the whole system to fail each service had its responsibility scope and issue logging so we could easily find out which part of the system was causing an issue to ensure the consistency of the system on our automation qas wrote Auto tests on the major functionalities and the ones which often broke down that way we made sure that any issues on these parts would be found in the testing stage automatically before releasing the software and let's talk about data security issues to control the security of the data first we encapsulated the data and its exposure functions via apis after that API testing was run through all the apis to check if more than necessary data is exposed to the client side um next problem is flexibility and compatibility issues keeping in mind the the importance for the business to integrate with other modern Technologies we re-platform some parts of the application by almost not touching the original Legacy code but instead having wrappers around it in the front end we handled it by using web components and on the back end via apis and next problem outdated Technologies with no official support outdated Technologies come with many many issues they have no official support there are fewer and fewer professionals willing and capable of working with them and implementing new features or fixing defects takes way too long and after having separated responsibilities into microservices it became possible to refactor sessions separate separately by upgrading to newer Technologies which were safer and had official official support and in the front end we embedded uh the neurotech angular app inside the old structure so uh we could work with newer code inside the Legacy one this also made it possible to do new feature developments faster and newer Technologies without stopping the addition of new business features uh next one let's talk about low performance issues overall the applications were rich in functionalities with having manipulations with big data portions and to increase the performance of the system we optimized the memory usage by refactoring to using correct data structures instead of default runs and re-architecting to high disposable pattern for freeing memory when the data is not in usage and synchronous calls from the user interface were transformed to asynchronous so users didn't feel the phrase of the application even on time consuming actions since a lot of necessary unnecessary data was being loaded from the database we refactored it to retrieve only necessary columns and added early filtering and paging so users could lazy load the data in Parts when necessary and of course almost no modernization process is complete without rehosting there's so much to speak about regarding the processes of rehosting and cloudy enablement yes and that's another story to tell as containerization and migration to cloud is a big big topic we are going to have a separate webinars session for that yeah I mentioned it just so you know that happened here as well you're good uh so dear audience please please stay tuned and we will update you about the next webinar session soon um Ani thank you very much for your thorough presentation of past projects uh and their Solutions uh but related to this I wanted to ask you both can you mention some of the outcomes of this effort from a technical and business perspective and what's the modernization process overall beneficial for the client side well I don't want to say that everything was ideal but it was infinitely better than what the clients had before the transformation to mention some of the benefits I can say that users stopped experiencing timeouts or frustration because of low speed and we could have months without system failures when before that was happening a few times in a day even yeah and from business perspective let me just mention a few uh so businesses could start focusing on the new feature development alongside with the processes of Legacy transformation because uh even if you need the Legacy transformation your business needs to go forward so this is very important it could happen quicker and uh of course as the systems became more scalable it was possible to integrate with third-party application uh many applications that we understand that currently in this timing it's very important for any businesses to be able to integrate with each other yeah and honestly working with such systems started becoming a pleasure for both for us and for clients I have wonderful uh so I will try to sum up that Legacy transformation can provide the range of benefits to businesses including improved scalability better integration with third-party applications and the ability to develop new features alongside the transformation process so upgrading Legacy systems can also eliminate issues such as timeouts and system failures resulting in a more enjoyable experience for both users and Developers uh the overall Legacy transformation can help businesses take competitive and increase efficiency by providing better services to their customers now we have some extra time let's go through the questions that our audience asked so let me pick the first question there are some questions coming out just a second I will try aha so uh the first question um have you had any experience of increasing the speed of getting data from the database let me take that one yeah yes for optimizing data retrievement from database we have used caching mechanisms in particular readies and in memory cache for data that wasn't changing very often but for data which was manipulated more frequently we have used elasticsearch okay uh now let me move forward with the other one uh what experience do you have in making a full assessment of the application landscape where all applications are not known due to uh for example acquisition of companies and thereby are known applications okay let me try to answer to that um so we have had in our experience Legacy systems that came to us that had a lot of components with third-party businesses if I understood the the question correctly and most of the time this third party application contacts were unavailable and we really didn't know how these systems could interact with each other so uh when changing something and breaking something it was unknown if we broke something in this other application components so what we have done of course we try to reach out to understand if there is any documentation what is going to be transferred between these two systems and most of the time as we couldn't understand that what we did is we know the interface how the systems interact with each other so this interface had to to stay untouched so we modified the code we do the restructure the architect everything but we have to make sure that the end result that the system exposed to the other applications has to stay constant usually it was an old format system XML based data so we just made sure that even if all our application data was working in Json format when interacting with these unknown applications we had to pass this old versioned XML format so yes we have headed even now we have these new technology systems that still interact with are no businesses but we push the xmls and sometimes we get the answers so we just know it's working and our monitoring just says that on code level there are just no errors if I answer the question yeah okay let me move forward with the other one um so after wrapping your data exposure with apis how were you still sure that no unnecessary data was being retrieved by users um of course we used permission checkings for all the api's calls and we have used role-based asp.net identity and for some custom cases um action claim based checkings so the next one um what experience do you have with replay with replacing client solution when a restructuring of bigdb is required to meet new business requirements and architecture thanks thank you for your question um I just remembered one experience so I can tell about that so um we had a monolith application that came to us it was big enough it was existing a few years and we decided to change it to monolid so uh that was the case there was of course a big database because it had a lot of functionalities and everything was uh centralized in 1 DB so what we did um to stay in touch with the client um so very closely our guys went to the business trip and for a month almost for a month we stayed together and we did these separations so what we did first of course we couldn't break the database to some parts so first in the monolith code we separated the modules that were going to become micro Services later just physically in different folders so logically we could separate them after the comment sections we moved to some let's say common folder and we prepared ourselves to go to separation what we did all the modules became microservices the common ones became packages that all microservices could use and as we separated the modules with their domains it was let's say comparably easy and understandable how the database was going to break because as we had the domains separated we could separate the database and it's still an ongoing project and currently with that application we have something like 30 micro Services some of them do not have a database it's not necessary but for most of them all the databases are separate so I think that's an experience that we did yeah it just took a very hard one month work from us to fully concentrate on it and clean the flow okay so let me move forward with the next question uh please tell about your experience in terms of upgrading whole project versions yeah let me tell about that a bit we have done upgrades from.net framework to dot net core and
if the application if the application is rich in functionality it usually uses a lot of packages and the most challenging part is to make sure all the packages versions talk to each other and the same from the front end because the same challenges we had met in front-end part when we did angular major version upgrades so we had a lot of packages and the most challenging part yes again was for these packages versions to talk to each other it's not an easy thing um another question uh is it possible to work on the Legacy applications and on the Legacy application and deliver new features along with modernization I I think I've mentioned that in the presentation um so um of course as mentioned this approach is possible that's something that is called continuous modernization uh that's when some parts of the system are being modernized let's say by separating the others are being developed or changed can be done with the same team or separate team again uh yes so the short answer is yes it's possible and most of the cases that's what the client wants because he doesn't want to stop the business and focus for a few months on modernization uh usually what they want is the business to go forward but to dedicate some resources time and money let's say to modernize it let's say in a continuous way okay another question from Rahul any automation tools used for modernization well automation tool honey have we had that I guess no no no automation tool now I remember we were researching a tool that we could convert an old access code to Doc net code um there were some ready Solutions it was an automation tool but eventually we did not pick that uh because it didn't match for the custom cases it was it was very generic so we thought that if we do that uh we are going to rework on it anyway I don't remember the tool name I just remember it were from access to.net if it's about automation tools uh from testing perspective of course we have that in our automation Frameworks but that's nothing that's not a tool for modernization yes those are the tools that are just used from testing purpose just as an animation to evaluate the functionality how it was and it stays the same okay so as a tool only the access and dotnet others were all Uh custom because we didn't have many language changes and that one was a language change if I'm not wrong any other questions Miriam um you are muted Miriam I'm so sorry uh so uh the other question is have you a problem for integration data between newly architected project and Legacy project and how to handle exceptions between them integration data between new and old um I understand it in two ways one um one is that when we re-architect the data structure is changed maybe how we evaluate that it's correct also another project comes to my mind an ongoing project where we are doing a complete refactoring I would say rewriting and how we evaluated everything is correct we manually check the database the old structure and the new for the scripts to give the same results the select scripts because the results here and here should be the same is just how the data is kept yes it's restructured if that was the question so yes we had that problem and very often in that case our testing is based on DB so even our qas um are testing that the modernization is done not only by application and UI manual and automation but also by database so with SQL we know how it was in the old database what was the result the same result should be here with another scripts of course but the data should give the same things and exceptions between them um exceptions between them if it's about the errors again from the testing phase it was becoming real again from manual and from automation because if there is an exception and error in the data not integrating between each other it's going to be resulted either in the logging system if it's not visible either it's going to be visible in the application which our keywords did not miss but I can add something about that and restructuring in DB is possible even in the same DB um to separate the data from uh one car one column to another table or something like that we have done that with help of migration scripts and of course we have tested it before doing that in inclined side DB yeah okay I think this much with the questions if there are some more left so we are happy to answer them after the webinar session and as we conclude uh I want to um say that uh like remind you that uh as a token of appreciation for your participation in this webinar we are offering a free consultation to all registered attendees for your software assessment so to take advantage of this opportunity you can simply follow the link provided on your screen uh to book a time and we'll reach out to you for the consultation process set up uh so um I hope that today's webinar discussion was insightful for you dear audience uh of course there's a lot to learn and um we got lots of input when discussing real life concerns and problems with their Optimal Solutions uh but clearly there is also a lot to discuss so it just reminds for me uh to say a huge thank you to our speakers Nune and Annie thank you girls for your input and um yeah I hope we will meet once again uh during our next Edition so stay tuned for our next Edition so follow Tech talks have a nice one uh and bye for now thanks everyone thank you guys bye goodbye
2023-03-11 01:02
