Since the early days of cloud migration, the fear of legacy applications going obsolete has plagued business leaders. Their distress deepens as cloud-native applications rapidly populate the stack intensifying the pressure to modernize their older counterparts. Some companies are going for wholesale modernization, and some, squeezed by runaway costs, are getting creative.
Paul Nashawaty, practice lead at The Futurum Group, and the delegate panel at the AppDev Field Day event explore why, in order to gain the most return on investment, enterprises should focus on the reasons to do it, than getting obsessed with the hype. The conversation describes how they can enact the change that most benefits the business and its people in a way that actually works.
Something More Modern
The concept of app modernization is often misconstrued and viewed as the goal rather than a means to an end. Like all transitions, application modernization comes with both opportunities and challenges that organizations cannot absorb or overcome frictionlessly.
Questioning whether the effort will actually benefit the business is an essential first step.
“It’s never just a technical decision,” says Mitch Ashley, Techstrong Research analyst. “There’s a reason behind what you are modernizing and why, and what you want to get out of it, rather than just refreshing technology. Oftentimes a lot of those things live forever. We don’t always get away from them.”
Undoubtedly, there is benefit in repatriating some legacy applications to the cloud. But trying to do so for every old application in the stack can inadvertently hurt the business. “Part of the challenge is you never have enough time or money to rebuild it all,” he continues. “One of the strategies is identifying what part of the app could really benefit the most from the flexibility and adaptability of the cloud.”
A Thorny Problem
There are several hurdles to software modernization at enterprise scale. Rebuilding is a messy process riddled with hiccups. The turnaround is slow and, and it frequently spirals into a horror show.
Deciding what needs to be refactored is another worry. It’s not a walk in the park when you have tons of old-fashioned applications, and they are all working as expected.
Demonstrating the value in refactoring is essential to optimizing investment. The argument most leaders put forward is that there’s a technical debt attached to legacy applications.
Calvin Hendryx-Parker, co-founder and CTO of Six Feet Up, agrees. There are two drivers that propel the decision of refactoring, he says. Tech debt, and user/developer experience.
“End users have higher expectations for usability inside of these applications because of what they experience on their own devices. They want the same level of interactivity,” he says. “From developers’ standpoint, those who know about heritage apps are going to become scarce eventually, and it’d be difficult to entice new developers to come and work on these old applications.”
There is no straightforward way of quantifying the losses from either of the scenarios. “It is hard to put a cost around it other than you’re going to lose talent and users, and ultimately, your edge,” he adds.
Not All Legacy Applications Are Made Equal
According to a Futurum Group research, 67% enterprises believe that app portability is vital. Cloud is the new paradigm, and with edge emerging as the next stop, portability is imperative to application longevity.
But not all legacy applications need to be refreshed from ground up. Sometimes, getting them to a cloud-ready state is enough to repatriate them. engineer and content creator, Michael Levan, insists that enterprises should base their decision on the choice of destination.
“If you want to decouple applications, turn them into microservices, containerize them, your application stack needs to have the ability to do that. Some application stacks simply don’t because it’s how the code is written. A lot of Windows-based containers are for legacy-based applications, for example. So if you don’t have a destination to run your current stack on, you have to refactor if there’s some type of need for it. You have to either figure out a destination where it’ll work, or have to do some type of refactoring.”
Although in many scenarios, refactoring is the ideal thing to do before plucking an application from on-premises and catapulting it into the cloud and beyond, and companies would be all for it if money was free, the reality is a bit different, says Kati Lehmuskoski, entrepreneur and author.
“In reality, what is happening at companies is that there are these apps that provide competitive edge, like a customer portal. Those get refactored first. And then there are applications that are working fairly well for companies and there’s no mandatory need to replace them until the technology gets very very old, and they become a security question.”
There is also a heavy cost burden to it. “When you look at individual applications that organizations own, it gets cost-prohibitive and time-intensive to really refactor for altruistic reason,” points out Josh Atwell, IT veteran turned developer relations leader. “Today’s innovations are tomorrow’s technical debt. So, it’s really hard to get ahead of that wave and actually get an application, especially a meaningful one, refactored and modernized.”
But that is not to say that organizations are not looking at application modernization as a realistic and workable goal. A small number of businesses have gone through with it with relative success.
“The organizations that have looked at applications and done refactoring in a meaningful and complete way are those who have repeated services and multiple applications that they need to simplify into shared services – extract them from large applications and create shared services for things like payment processing, inventory, customer loyalty programs, etc.”
In the end, it should create value, or none of it is tenable. Alan Shimel, founder and CEO of Techstrong Group says, “Without a compelling economic ROI that is business talk at the C-level or board-level, you are not going to be able to push through a large-scale app modernization because it’s cool. It’s dollars and cents today, and it’s got to make business sense.”
Modernizing at scale is unnecessary when old applications are working well. “A constant effort to simplify prevents the mounting of the complication and that’s where companies are at. Each one of these new waves demands a new style and approach and a new set of applications and capabilities, but it doesn’t get rid of the old immediately,” says Guy Currier, chief technology officer.
Innovation Vs Operation
The age-old contention between innovation and upkeep casts a long shadow on organizations’ modernization efforts. Nashawaty pointed to another Futurum research that indicates that developers spend more time maintaining the applications than they do innovating, and given a choice, they’d like to invest more time in the latter.
“AppDev and apps don’t exist in a vacuum, but to support the goals of the business,” Jack Poller, cybersecurity industry analyst, comments. “When we go to refactor applications, there has to be a clear understanding of what it is and how it will support the business,” he insists.
After cost and complexity, cybersecurity is the next big concern. Typically, monolithic applications have a wider attack surface that makes them ripe for cyberattacks. Refactoring often slims down the surface, making the applications inherently more secure.
But Shimel predicts that security is not going to be the driving force. “Security does not come until customers demand it. So, for a lot of this stuff, security is playing catch-up and is bolted on. When we first started moving stuff to the cloud, we called it cloud washing. All too often that’s what happens,” he comments.
For really old technologies, the primary concerns are security vulnerabilities and end-of-life components. Hendryx-Parker insists that vendors should tighten their belt and be clear out the gate about the implications of using such technology.
“Vendors have to be willing to say the hard thing to buyers that they need to update and refactor and stay patched, or the seller is not going to be responsible for what happens because of their poor decisions.”
Wrapping Up
Keeping a fleet of old-fashioned apps that are a burden to maintain translates to unhappy stakeholders and snowballing technical debt. The opposite scenario is a full and complete overhaul that costs a fortune, has major technical challenges, and does not necessarily yield the expected value. The answer that enterprises are looking for is in the middle. Being guided by facts and goals, rather than by the impulse to chase a fleeting trend, application modernization can be the change that solves a lot of enterprises’ problems and produce happy users and employees. But a measured and calculated approach is a must to reach that destination.
Be sure to listen to the entire conversation from AppDev Field Day on the Tech Field Day website. Also check out Alan Shimel’s article on AppDev Field Day presentations, and Paul Nashawaty’s coverage of the Google Cloud session.
