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.
I call bulls***t.
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 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.
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:
Lift and shift is just sweeping the problem under the carpet.
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."
The same thing can be true for and Delphi and PowerBuilder and Informix. In the web world it's ASP Classic or ASP.Net with web forms. You get the picture.
If you put a beautiful, 12-coat, hand-rubbed paint job on a 1967 Ford Mustang, it's still an old car. It may look good, but it's not a modern car. It doesn't have disk brakes. It doesn't have ABS. It doesn't have fuel injection. It doesn't have air bags and shoulder belts and crush zones and all the rest of the things that keep you safe. The things that make it reliable. The things that make it economical.
In short, there's nothing you can do to a 1967 Mustang to make it as good as a 2019 Mustang.
You can put a VB6 application in a virtual machine and think that you've modernized it, but you haven't. You still have an antique application. It's hard to maintain because the language is no longer taught in schools and young developers don't want to sully their hands working on it. The developers who will are either past retirement age or almost there; they are rare and expensive and know it. After they retire they will offer to work on your code as consultants for 3X the hourly rate you used to pay them. And you'll be happy to get them. The UI of your app looks exactly like what it is: something designed in the 1990s. The runtime and libraries it uses were not designed with 2019-levels of understanding of and experience with the last 20 years of app security improvements. Automatic updates to Windows operating systems might cause one of the application dependencies to stop working over night, bringing your app to a complete standstill.
If you've read this far you're either a masochist or you've got one of these apps and it's still delivering value so you can't kill it.
But you don't want to keep it like it is.
The business value is there, encapsulated in the business logic and rules codified in the source code. It works, because over the years it's been in production, the bugs have been found and fixed. Sure, the code may look pretty horrible after so many surgeries, but it works. If it didn't work, you would have discarded or replaced it long ago.
The brain, in other words, is good.
The body, on the other hand, is shot. Old language, old libraries, old components, old runtime. And it's the body you have to keep working on.
What you need is a brain transplant.
Most people will tell you the only real solution to obsolete legacy apps is a ground-up rewrite. Start with a clean sheet of paper and party on! Write that perfectly designed and coded application like you always wanted to. Use perfectly designed classes, write all the tests first and then the code to implement them, create UML diagrams and perfectly commented methods. There will be no bugs, the users will sing your praises, and developers far and wide will bow down at your magnificence as you walk past: the greatest programmer to ever live!
Right.
If you've ever written any raw code longer than hello world, you know that's a bunch of nonsense. In a perfect world you might do perfect work, but it will take forever. And this is not a perfect world. Your bosses want it yesterday. The users keep changing their story. No one is sure which other systems you have to integrate with, so better integrate with all of them. Let's use Angular JS, no Angular Not JS, no React, no, let's change it again. And by the way, we still need to keep the legacy system up to date, so just squeeze that in, ok?
Recently I sat in a customer's conference room and the head of development told me--after rewriting a key application already twice over a 20 year period--they would do almost anything to avoid rewriting it again. They knew from experience just how difficult writing new code is. They knew how long it would take and how hard it is to manage schedule and resources. For them--like many others--automation migration was a life-saver.
There's a reason we hear from similar customers who started down the rewrite path and gave up. It's hard, it's risky, it takes forever, it never seems to get done. Migration with tools like VBUC or WebMAP, however, get that working business logic (the brain) into a new body (C#, Angular, Java Spring, VB.NET, TypeScript, etc) quickly and efficiently. The code is modern, the platform is current, the language is familiar to both your current dev team and new hires right out of school. The guts of the application have been replaced without blowing the budget or the schedule.
So when you hear promises from companies about legacy application modernization that involves "packaging" or "containers" or "virtualization" you should ask yourself do you want to shift the problem or solve it? Cling to the past or embrace the future? Because if you've still got VB6 or PowerBuilder or Delphi you're not talking about app modernization.