VOLO Tech Talks - Legacy Applications Modernization

Show video

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

Show video