Debunking Modernization Myths
September 14, 2022 Alex Woodie
If you’re embarking upon an application modernization project, you’re not alone, as many organizations running older computer systems are looking for an upgrade. But that increased need for modernization has coincided with the rise of several myths on the topic, which is a cause for concern.
The first modernization myth is that all you need for a modernization project is a code converter that takes your legacy source code and automatically converts it to a modern codebase. While code converters do have a role to play, there are many more important aspects to a successful modernization effort.
“The spin being given is it’s quick,” says Miten Marfatia, the CEO of EvolveWare, a Santa Clara, California-based modernization tool provider. “If you’re saying you want a silver bullet, that I press a button and my application gets modernized, that’s not going to happen.”
Many vendors of code converters are making misleading claims about the capabilities of their products, and that’s hurting customers and distorting what modernization tools can reliably deliver, Marfatia says.
“I’ve had clients tell me that we need about a week to set up our tool and then it’s almost 98 percent of automated conversion,” he tells IT Jungle. “But they won’t say that prior to that, I need six months to look at my code and modify and customize my product. So those kinds of expectations need to be correctly set.”
Rushing to beat the clock will not make a modernization client more happy in the end.
Code converters have a place in application modernization environments, particularly for well-documented systems that are already providing the functionality that the customers wants or needs, but just doesn’t run on the platform the customer wants or needs it to run on. In these instances, code converters can help move the code, although there is still usually a bit of cleanup necessary.
A more involved modernization technique centers around business rule extraction. Documenting the business rules in an external repository can help a customer be prepared to take the next step of rewriting those business rules in a different language, or using a standalone business rules engine to execute those rules in a different platform, Marfatia says.
Another myth making the rounds is that business rule extraction is too time-consuming and tedious for a company undertaking an application modernization effort. In fact, it’s a good step for many projects, particularly for those that will see a good deal of new capabilities brought to the application, Marfatia says.
“What we recommend is, if you want to enhance an existing application substantially, then don’t migrate it [with a code converter] because it’s not going to give you everything you want,” he says. “Do not convert it to modern code, because you want different functionality or enhanced functionality in your application than what you have. You are better off extracting the rules you want to keep, and then either rewriting the application or moving it to a business rules engine, where you can add new rules.”
If it sounds like this will all take a bit of time, it will. Successful application modernization efforts can take several years, in many cases, Marfatia says.
“As you know, with all software development projects, there needs to be a certain tolerance for time as well as cost,” he says. “You want to make sure that your plans let you come in within in the tolerance of your budget as well as your time. Give yourself a 20 percent tolerance. If it’s three years, say between three to four years.”
It’s tempting, but don’t do it. (Image courtesy Reverent Geek)
In the same way that you can’t outsource your problems and expect a good result, you shouldn’t expect a third party to solve all your application modernization issues and expect to be happy with the product that comes out of it. As the owner of the code and the application, you should be closely involved with every step of the process when using a third-party provider.
“When we speak to clients, we make a few things clear,” Marfatia says. “One is please don’t look at this in a manner where, I don’t want to have anything to do with this. I’ll give you the code. You come back with the results. You want to be part of the process and you want to understand the methodology.”
EvolveWare primary is a vendor, and its modernization tool is called Intellisys. But it sometimes gets involved in client engagements, particularly when it comes to running Intellisys.
“You cannot just walk away,” Marfatia says. “You as a client, you want to be invested in the process fully from the standpoint that you know exactly what is being done and that you are approving of the process being followed.”
While the business is crying out for better capabilities (containerized microservices in the cloud now!), rushing through the modernization process will likely create more problems than it solves. Being methodical and completing each step before going to the next step is the best way to keep your options open and guard against costly mistakes, Marfatia says.
Want to run your applications as containerized microservices in the cloud? You have your work cut out for you.
This is particularly important when it comes to documenting the system its business rules. In some cases, after documenting the rules, the customer gains a new perspective and may decide to keep the application on the platform it’s currently running, to shift the rules to a business rules execution, to continue the migration to another platform, or to make some other change.
“When you go and document the current state of your systems, you’ll start recognizing the potential pitfalls. That’s when you really come together and plan and mitigate your risk,” Marfatia says. “There is a process that needs to be followed.”
The last myth for today is that the customer always knows what’s in their code. The customer may always be right in fairy tales, but in the real world, the customer is occasionally wrong.
“The biggest problem that we run into is setting the right expectations and convincing the client,” Marfatia says. “I sometimes am surprised when we tell a client we need to process your code and create a repository of all its different artifacts so that we understand what the current code is doing, their response many times is ‘Oh, we know what it’s doing, don’t worry about it.’ We say, yes but you can’t be dead certain unless you have something written up or some documentation.”
Several times, EvolveWare has documented its client’s code, only to find that their code was not following the latest industry regulations, and they had no idea this was happening.
EvolveWare has worked extensively in mainframe modernization projects. It plans to support RPG with Intellisys in early 2023.
RELATED STORIES
EvolveWare Sees Growing Demand for Application Rehoming
Want to Modernize? Great! Now Get to Work
