Skip to main content

Building a Digital-First Strategy With IBM i

When it comes to modernizing IBM i environments, often the biggest challenges aren’t technical. Many enterprises simply don’t know where to begin.

Puneet Kohli sees it all the time. As president of application modernization at Rocket Software, Kohli is charged with helping clients navigate the challenges and recognize that IBM i is well-suited to help them achieve their modernization goals.

This process typically starts with simple reassurance. That’s because when meeting with IT personnel, Kohli says he can count on being told one of two things from the onset. “Anytime we talk to a customer about modernization, the first thing we’ll hear is: ‘Modernization is going to be too hard,’ or ‘I don’t know where to start.’”

In March, tech industry analyst IDC published a white paper, “How IBM i Can Play a Pivotal Role in Supporting a ‘Digital First’ Strategy.” In the paper, which is sponsored by Rocket Software, IDC notes that IBM i systems, workloads and applications are often limited within or excluded from organizational modernization initiatives due to the perception that they are too costly and complex to manage.

IDC then highlights key modernization requirements and details the platform’s unique attributes, concluding: “In today’s increasingly digital world…there is no avoiding including IBM i in a digital-first strategy. Too many critical applications run on IBM i for thousands of companies worldwide, and these applications require a platform that is included in continuous modernization in order to deliver new capabilities and services…IBM i is a solid, modern and future-proof platform for enterprise-class computing that organizations should invest in and integrate with their evolving digital-first IT landscape.”

Breaking Down Misconceptions About Modernization

In dealing with clients, Kohli sees his role as providing information and education. Sometimes that requires addressing the misconceptions of someone unfamiliar with the IBM i platform. In an anecdote that will surely strike a chord with long-time programmers and administrators, he recalls a meeting a new CIO whose company had inherited an IBM i environment in an acquisition.

“He’s questioning why they’re using this application that’s 20-plus years old. He wants to move off of it,” he says. “And I just say ‘look, it supports Python.’ His eyes start to widen. ‘So you’re telling me these kids (programmers) that I have back there, they can take it?’ I said, ‘Absolutely they can.’”

“IBM i, RPG—they’re not used to those terms,” Kohli adds. “So you just have to help them through it, using terms that they hear.”

As noted in the white paper, this lack of familiarity with IBM i also plays out in another way, when organizations that rely upon disparate computing platforms confine their modernization initiatives to Windows or Linux.

“There are also applications running on Windows and Linux that were written many moons ago, but people are more comfortable talking about Windows and Linux, so they put IBM i on the back burner,” Kohli says. “However, it’s the same conversation, and if you don’t also bring in the people who are running your IBM i, those conversations about modernization become even harder and you fall even further behind. It’s important to break down those silos.”

Modernization Is Possible

The angst is understandable. It is daunting to think of an application written more than 30 years ago still performing business-critical functions, knowing that the original owners have most likely long since left the organization. Kohli acknowledges the process isn’t simple, but there is always a logical starting point. For example, with one client, Rocket was about to demonstrate that their monolithic application was only using 20% of the quote path. Another client was reminded that APIs (hello, Python) can be used to connect legacy applications with modern systems.

“Many times, it just starts from letting us, or letting someone else who does this sort of thing, give you a view into the application,” he says. “Once you can see what the application is doing, you can approach it like any other software application. So, follow the same software development principles. You may just take the front end and build a Reactor connector to it. Go from there, do your two-week sprints, and you start seeing progress. So yes, it’s hard, but it’s not that hard. You can get there.”