Loading...
Tech Trend

What We Talk About When We Talk About Application Modernization

1011-14

I just finished reading a white paper from a highly-respected technology company about their definition of application modernization. Their definition of application modernization is “repackaging” legacy applications for “more agility” including some “cloud native” features.

What exactly is application modernization? Like so many tech-born terms, people feel free to define and redefine it. But for starters, let’s look at how Wikipedia defines software modernization:

Legacy modernization, or software modernization, refers to the conversion, rewriting or porting of a legacy system to a modern computer programming language, software libraries, protocols, or hardware platform. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms.

There are some key terms here that I think are required for any actual software modernization effort:

  • Legacy system: Not just old: legacy systems are based on obsolete or unsupported languages, runtime platforms, and operating systems. IBM 360 assembly is legacy. All COBOL is legacy. Visual Basic 6 is legacy. Windows XP is legacy. Anything that depends on 16-bits is legacy.
  • Conversion, rewriting, or porting: Modernization isn’t about “lift and shift.” It’s not about sticking old crap into a VM. It’s not about hosting in Azure instead of that Dell server under Harry’s desk. It’s about actually changing the app.
  • Modern computer programming language: This is the real nut of the problem. All applications are written in code, and anything written in an old programming language is harder and more expensive to maintain than something current. You cannot modernize a legacy application without changing the programming language. Anything short of that is just putting lipstick on a pig.
  • Retain and extend the value: If you’ve got a legacy system, it has value. Otherwise it would already have been shut down. Legacy systems are too much trouble–too expensive to maintain–to keep running unless they deliver a lot of business value. Y2K–only 19 years ago–freaked everyone out not because of the end times predictions but because they had to touch truly ancient legacy systems, which were still running because they were so valuable. And having touched them, they are largely still out there.
  • Migration to new platforms: A VM running Windows XP hosted on AWS is not a “new platform.” It’s a dangerous, out of support, obsolete platform, regardless of the appeal of wrapping it up in a nice container.

Legacy systems are a big bowl of wrong

Legacy is a huge problem–Gartner estimates up to 70 percent of the Global 2000 IT budget is spent on legacy application maintenance. The US government spends 80% of its IT budget on maintaining legacy systems, some of which were written when John Kennedy was president.

  • Legacy systems block adoption of modern engineering practices like DevOps
  • Legacy systems block ISVs from moving to a SaaS (subscription) model
  • Legacy systems have inferior user experiences (UX) leading to a loss of efficiency
  • Legacy systems require developers approaching or past retirement age–both rare and expensive
  • Nobody wants to work on legacy systems
  • Nobody wants to run legacy systems
  • Legacy systems are a huge PITA.

Real application modernization isn’t lift and shift

Lots of vendors–SIs, consultants, public cloud companies, virtualization and containerization companies, and possibly your Great Aunt Sadie–will try to sell you a solution to your legacy application problem that involves “lift and shift.”

Think of it instead as lift and s**t.

The problem with lift and s**t is that it doesn’t solve any of the root problems your legacy software is causing:

  • It doesn’t replace the obsolete programming language the source code is written in.
  • It doesn’t provide a pipeline of new less-expensive developer talent to work on it.
  • It doesn’t have a modern UI.
  • It doesn’t move an app that is captive to the desktop to the web.
  • It doesn’t improve integration with other systems.
  • It doesn’t allow for DevOps.

Lift and shift is just sweeping the problem under the carpet.

Application modernization requires modern programming languages

Abraham Lincoln once asked, “If you call a tail a leg, how many legs does a dog have?” Upon being told “Five,” Lincoln replied, “The answer is four. Calling a tail a leg doesn’t make it a leg.”

Calling a VB6 app “modernized” because it’s running on a VM doesn’t make it modernized, regardless of what people tell you. If the source code is VB6, there is literally nothing you can do to make it modern without replacing the VB6 source code with something contemporary. It could be C#, or VB.NET, or even Java or JavaScript, but it cannot remain written in VB6 and be called “modernized.”

READ MORE : What We Talk About When We Talk About Application Modernization

Leave a Reply

Your email address will not be published. Required fields are marked *