Assessing IBM i’s Role In Digital Transformation

March 20, 2019 Alex Woodie

There comes a time in every application’s life when its owner must take a hard look at its continued viability and ask the tough question: Will the application continue to meet the business’s evolving needs, or should the whole thing be scrapped for something new? These business and technology assessments can be especially tough when the software runs on the IBM i server.

Many companies these days are looking to modernize their aging IT systems in the hopes of gaining more agility and flexibility. Whether you call it digital transformation or application modernization, the goals are often similar: Simplify the underlying code base, improving code maintainability, and making it easier to implement new functionality or integrate with outside systems.

In many cases, these modernization/transformation efforts call for eliminating the monolithic codebases that typically defined applications developed in the 80s and 90s. Instead of complex programs composed of millions of intertwined lines of RPG or COBOL code, organizations seek to break up spaghetti code into more discrete chunks, which can be exposed as microservices, often generated in more modern languages, like Java, Python, or PHP. This step alone can improve the agility of the software engineering team by making the code easier to maintain and run (not to mention allowing the HR department to pick from a bigger pool of IT applicants).

The IBM i platform, owing to its legendary stability and reliability, runs more than its share of monolithic legacy codebases, which means that it’s often the target of modernization/transformation initiatives. Technology consultant Bill Kleyman has been in several such technology assessments, including one recent engagement that involved migrating an aging IBM i-based business application to the cloud.

Kleyman tells IT Jungle that this particular company, which he declined to name, had previously tried to migrate away from this critical IBM i environment in 2015 and failed. In 2018, the company – which is based in Canada and supports more than 600 stores and locations around North America – engaged Kleyman’s previous employer, EPAM Systems, and succeeded in migrating a critical IBM i-based application to the cloud.

Massive Cloud Migration

This particular migration was massive and involved 15 to 18 agile teams working in one-week sprints over the course of about a year, while the application continued to be used by the company’s 25,000 or so employees.

According to Kleyman, the migration involved reverse engineering 6 million lines of Synon and RPG code; rewriting them in Java using a micro-services based approach; migrating more than 1,000 database tables in Db2 for i to MariaDB; rewriting almost 200 integration points; moving from a traditional waterfall-style release cycle into an agile methodology, backed by Jenkins; and creating a new HTML5-based UI to replace 5250 screens (developed in a “like for like” manner so as not to disrupt the users).

Bill Kleyman is the EVP of Digital Solutions at Switch.

The level of technical complexity was high. Kleyman and his colleagues at EPAM – a 28,000-person IT consulting company based in Pennsylvania – had to create custom code-analysis tools just to document the old code before running it through a code-generation system to produce the new Java.

“There’s no boilerplate to make this happen,” he says. “You’re going for a swim here, man. It’s not an easy project — not by any sense. It’s complicated. It’s surgical. It involves many different team members, from data scientists to agile team members to people who are RPG developers.”

The IBM i platform hasn’t been completely eradicated from the company, and there are on-going efforts to continue refactoring other pieces, Kleyman says. But successfully moving the company’s core business application to the cloud has been a real game-changer for the company and opened up new online business opportunities that otherwise would not have been opened, he says.

“This was not an easy project,” Kleyman says. “But when it happened, you saw the unification of the entire business. All of a sudden, this company that had this legacy IBM AS/400 ecosystem just created their own digital foundation, a foundation that can be integrated with the ecommerce systems and cloud. Their DevOps team is no longer fearful of release cycles. They have so much more control over data and data analytics, and the ability to integrate with other kinds of data intelligence systems.”

The company runs the new Java-based application on the Google Cloud Platform (GCP), and experienced up to 50 percent better performance and greater uptime, Kleyman says.

“When you remove legacy IBM systems, which are very static and resource commanding, and put some of those micros-services in the cloud, where all of a sudden you have consumption-based architecture where you only consume what you need – it’s a complete paradigm shift,” he says.

Business Assessment

While the technical bits can be challenging, Kleyman said the biggest hurdle to successfully complementing migrations involves people.

“This is going to sound silly,” he says. “The hardest part isn’t necessarily the refactoring. The hardest part is convincing people to do this. Because, let’s be honest the upfront cost can be very scary, man. It can be frightening. The business is going to say, ‘We just put in X amount of dollars last year to support these kinds of environments.’ You kind of have to ask the question, what’s going to happen five years from now?”

While the legacy application may not be “broken,” forward-looking companies will consider the lost opportunity costs that are inherent when an existing system is not agile enough to support new opportunities and initiatives.

“You’re going to have to have the conversation where you can’t integrate with cloud at all, or you can’t integrate with data analytics, or you’ve failed to do cognitive system and your competitors are because RPG can’t support this stuff?” Kleyman says. “But just because it’s working doesn’t mean necessarily it’s bringing value back to the business.”

It’s easy for an executive to identify problems when servers are down, the application is throwing errors, and the day-to-day business is being impacted. It’s much harder for the executive to be able to identify the ways in which a legacy system could put hamper growth in the future.

“Honestly that’s one of the best approaches, when things aren’t on fire, to start asking some of these difficult questions,” Kleyman says. “It’s kind of like in a relationships. When everything’s going great, you don’t want to bring up any sore points. But realistically speaking, you don’t want to start arguing when everything’s wrong and you start bring up the pain points.”

Platform Vs. Application

Doing a technological assessment to determine the long-term feasibility of critical IT components is important for any company, whether its system runs on an IBM i servers or lives in the Amazon cloud. But, for better or for worse, the technological discussion is a bit cloudier for the IBM i customer, because the legacy application so often gets tied up with the platform that it runs on.

Separating the IBM i server from software applications is a difficult task. While we know that they are different things – one is a computer platform while the other is a program that runs on the platform – they often get tangled up into a single ball in our minds. The attributes of a particular application will get superimposed onto the platform itself, to the point where decision-makers view them as one and the same thing.

When companies say they’ve become dissatisfied with the AS/400 – really the IBM i platform — they often have a specific application or a group of applications in mind. In many instances, the applications are quite old, have not been updated for years, and do in fact pose a liability for the long-term viability of the business and its current strategy.

These companies often identify the IBM i server as the problem and migration from the platform as the solution, when in fact the real culprit is the legacy RPG or COBOL application that’s running on the platform. This is unfortunate, but it’s quite common. (The fact that they call it “the AS/400” is a major clue that they are not aware how modern today’s IBM i platform really is.)

There are cases where the platform itself is the roadblock. No other platform uses RPG, which translates into a limited pool of developer talent available on the open market (most IBM i applications are written in RPG). IBM i applications also do not run on public cloud environments, such as GCP and AWS. If your business strategy demands that you run in the cloud – which brings very real business benefits in the form of easier data and application integration – then the IBM i server clearly isn’t for you.

But for those companies that have invested millions of dollars into their AS/400-iSeries-System i-IBM i applications but are facing lost opportunity costs in the future and/or mounting technical debt, it’s worth considering the full range of opportunities that are available. Many of the benefits that Kleyman helped his Canadian client obtain – a cleaner, more manageable code base and a more agile DevOps deployment methodology – definitely can be achieved on the IBM i platform.

You don’t have to ditch the IBM i platform for the cloud to engage in digital transformation. There are great partners, software vendors, and solution providers in the IBM i ecosystem that can help you assess the state of your current code base and script a modernization roadmap that can (hopefully) get you where you need to be.

All that’s required is the courage to reach out for a little help from your friends.

RELATED STORIES

Wanted: Exciting New Publicist for Boring Old Server

Fifty Years Of Operating IBM Systems

The 1980s Were Great, Just Not for Business Computers, Apparently

The Problem With ERP

Keep Your IBM i Baby, Not The Bathwater

Squeeze Your ERP A Little Harder Before Ditching It