When we speak to businesses that run on the IBM i platform (aka AS/400 or iSeries), legacy and monolithic code are the top two compelling reasons cited by organizations choosing to start down the path to application and system modernization. But since “legacy” code has already done so much for us, why consider a change? Learn more in this, the first of three blog posts I’ll write on the topic!

Outdated or Established IBM i legacy code?

I was recently referred to as “veteran”, which initially offended me as I distinctly heard that as a reference to being “old” and perhaps the waning of my usefulness. But nothing could be more wrong. 25 years of assisting enterprise clients in appreciating their current IT environment, facilitating their understanding of how to evolve that environment to achieve their objectives, and executing on that agreed upon roadmap to success doesn’t happen overnight. I quickly changed my tune and proudly embraced the experience, struggle, and results that the term “veteran” conveys. However, it made me begin to wonder if my 25 years of promoting legacy modernization and transformation had perhaps had the same effect on people. The term “legacy” certainly has evolved to carry a negative connotation, but that legacy is what has built thousands of companies into what they are today. So, as we begin this conversation, I want to be clear that legacy code is not bad. Legacy is our heritage, and we should embrace it and place it on the pedestal it deserves. With that said, most people, including me, acknowledge that I am on the back-side of my career (30 years down, and 10-15 to go before retirement) and although I’ve still got a lot of value to bring, I have to begin thinking of “what’s next”, as does my employer and my clients. Likewise, organizations have to begin thinking of “what’s next” with their code base, as the legacy code (and supporting infrastructure) that has served them well may have a quickly approaching expiration date as to the ongoing value that it can bring.

Taking the emotion out of “legacy” modernization

So, as I started battling with this concept of legacy code needing to move to modern code, I found myself in religious debates about whether certain syntax is legacy or not. I quickly came to the conclusion that I needed to take my emotions out of the equation to look at this objectively, and that the best way of doing that was to look at an example outside of the IT space as an analogy. At the risk of making anyone feel old, I want to escape for a moment to the world of audio/video players and gently point out that the VCR/VHS was introduced in Japan in 1976 and the US a year later. It was an amazing machine. Consumers amassed huge libraries of blockbuster tapes to entertain themselves for indefinite periods of time. Families recorded personal events for future generations to reference. And all of that was possible because of the legacy that the VCR and VHS tapes brought to our way of life. But time changes, people change, needs change, and technology changes. As part of that change, the DVD player was released about 20 years later (1996). DVDs are physically smaller than VHS tapes, have a lack of moving parts which made it more reliable, store video and audio digitally instead of analog, and best of all there is no rewinding necessary. A great evolution, not to mention an amazing stepping-stone that set-up the market for future evolution. Fast-forwarding (no pun intended) to current times, streaming video has now gone mainstream, providing on demand access, almost infinite titles, plays on any device, and is perhaps one of the biggest saving graces during the 2020 Covid-19 quarantine isolation. Please be clear… the moral of the story is not that streaming is better than the VCR, but that the VCR made streaming a possibility. It is the legacy that makes the future brighter!

What is “legacy” code, anyway?

We’ll cover this more in my next blog post, but there is a consensus among some businesses that .NET and Java are modern alternatives to other IBM i programming languages. In actuality, both languages are close to 30 years old. There are other languages, like Node.js, that are much newer, are understood by younger developers, and that make modernization, integration, and portability of business systems much easier. Stay tuned for that. In closing (for now), you don’t have to nor should you be on one side or the other of legacy vs. modern…they are part of the same story. You need one to transition to the other. As such, please join me in taking the emotion that you might feel about legacy code, and channel it into positive future-thinking possibilities. Next time… We’ll look at the history of RPG, Java, and .NET, and if the term “modern” applies to any of them. In the meanwhile, you can learn from industry expert Scott Klement about the benefits of a modern language – Node.js –on IBM i in this on-demand webinar. Learn more about how we transform this IBM i legacy code with Profound UI.