IBM i Modernization: Modernizing Smartly and On a Budget

A lot of IBM i modernization discussions focus on strategy. In many of these discussions, the reader may walk away inspired with strategic motivation, but at a loss of where to start. What I’d like to do is skip all the strategy, assuming you’ve had enough of that, and focus instead on some of the tactical components of IBM i modernization that can bring significant returns with minimal investment.

What Is IBM i Modernization?

IBM i modernization is the process of updating IBM i applications to take advantage of new developments in software — whether that be new technologies, new features, new architectural styles, or new methodological approaches.

IBM and the development world in general have offered many new features to IBM i and the application development model. Some of which I will explore in the next few paragraphs. What I won’t do is pick a fight about User Interfaces or architectures, etc.. Like I said above, I want to focus on things you can do right now that will start showing a return on investment AND help you to bring your code to the “present.”

Why Modernization Is Important for IBM i Apps

Why should I bother with modernization? My apps are running just fine and no one is complaining. Yeah, right. There are several reasons including recruitment of skills, operational efficiency, better technologies, and others. But I’d rather let the examples speak for themselves.

Getting Started With IBM i Modernization

Modernization doesn't have to be all at once, nor does it have to be incremental (though incremental approaches will likely be more effective for most companies). Ultimately, there are a variety of approaches for IBM i modernization that can be effective. Pairing your modernization approach to the needs of your company, and your ability to execute that approach will be key in achieving them. I know I said I wouldn't talk strategy, so let's jump right into common modernization approaches you should (or shouldn't) consider.

All at Once Modernization

The first myth we need to address is the theory that we need to do this all at once. When in life do we do anything “all at once”. In every task from remodeling a home, to baking a cake to planning a vacation we break the task down into steps and smaller components. Do you wait until you’re ready to grill something to go shopping for steaks? Of course not. You add steaks to the shopping list and maybe a day or two later you grill them. But stop for a second and look at what I did there. I broke the grilling down to two steps and one of the steps is completely unrelated to the grill. Shopping is a separate step and has no dependence on even having a grill or not. Hold that thought.

Gradual Modernization Approaches

Chopping up the tasks and doing a little at a time is where we see progress, even if only incrementally. There are a few approaches I want to discuss that will help add value to the code base and allow it to be modernized. With each example I will not just espouse religious tenets of a modern developer, I will also cite the ROI opportunities. 

Refactoring 

Refactoring is the process of improving a code segment like a small RPG program or subprocedure or a PHP function or method without changing any of its inputs or outputs. That is not a hard and fast rule, but it works for the sake of this illustration. Now I know what you’re thinking: “If it works, don’t fix it.” But I am telling you that if it works and it’s written in an ancient style you have an obligation to fix it. 

Uncle Bob Martin, who is highly regarded in the clean code arena tends to make some very religious statements about application development. While I don’t agree with all of them, one I find very appropriate in where he states “Refactoring…is like washing your hands in the bathroom. You always do it.” 

His point is quite succinct and it implies that tidying a routine before finishing can help the code base. And when you do this as you are doing other maintenance, the cost is no longer “just modernizing”. Instead, the cost is distributed across dozens or hundreds of projects. The benefit is more maintainable and readable code. There’s a discussion about the ROI of that coming

One example I’ve seen my customers use is the replacement of record level access for SQL routines. I remember when SQL on the old AS/400 was slow and hardly worth waiting for. But today, thanks to the hard efforts of Scott Forstie and his incredible team based out of IBM Rochester, we see performance of SQL access surpassing that of RLA. 

The primary benefit of this level of refactoring is that you have now taken a routine and improved performance and made the code more readable to cross platform or new developers. Stop looking for RPG developers with 20 years of experience and focus on kids coming out of college with contemporary skills. They can do RPG/SQL. Don’t make them use RPG/400 fixed format code and RLA. It’s not worth the learning curve.

Another example is in PHP code where older routines written using older code constructs should be addressed. PHP over several releases has been moving aggressively away from global variables. This is a good thing, and I will talk about monolithic code in a bit. In my experience, the most insidious bugs were those where another routine stepped on a variable accidentally and messed up the code I was debugging. Leveraging scope by creating extra functions or methods not only reduces the number of global variables, it also tends to make the code easier to read. 

Why does that matter? Well you can read the survey done by Stripe 2018 where they discovered that the average developers spends about 4 hours a week wading through “bad code”. Extrapolated out for the worldwide development population, that comes to about $85B annually. And those costs have only gone up since 2018. 

Standards: PHP-FIG

Stop arguing about where to put the curly brace and just use the PHP-FIG. The PHP Framework Interop Group was created so that the many open source projects in the PHP landscape could work in an integrated fashion. The PSR standards that have evolved offer a community-based approach to writing code that makes easier and faster ($$$) to on board new developers. I recall shop standard being radically different from company to company back in the day. Today we have the advantage of solid linters in PHPStorm and others to help us remain consistent. 

NOTE: If you're looking for further reading, Paul Tuohy has a good RPG Style Guide worth checking out.

Testing

Have you heard of the great resignation? I’ll address this at two levels by discussing both the developers and the users. But let’s talk about testing first. Everybody does program testing of some sort (I hope). Many shops I work with rely heavily on User Acceptance testing or UAT. That is great, but it can be so much better if you include Unit Testing. 

Unit testing brings about two opportunities in that it can introduce automated tests to the code base and persistence. If you can be so bold, moving all the way to TDD would be the ideal in new development. Writing tests first and then the code, in an incremental approach can deliver the application often on the same timeline but now with unit tests. These tests are little routines that test the smaller methods and functions and subprocedures of an application as it is being built instead of waiting until the end of development. PHP Unit has been around for quite some time and I’m planning that for a future blog article. But were you aware of RPG Unit tests? You can learn more from examples created by developers like Marina Schwenk.

Good testing practices do have an ROI, but not in the way that you might expect. When your developer leaves, and they will leave at some point through a change of life, attrition, retirement, etc., they take their development knowledge with them. But they also take the business knowledge with them. This hits RPG shops excessively hard, as nearly all the RPG devs I’ve met knew more about the business than the users. This makes the transition difficult for all parties involved. 

But if we could capture some of the test behavior in scripts that are stored with the code, we have the opportunity of capturing some of the business knowledge forever! And the same goes for the super users in the business who test the applications being built. They are not immune from the great resignation either. You can capture some of what’s in their head over the course of several years of development, or in the last two weeks of their employment. Good luck with that.

Agile

Here’s the first fancy buzz word. A lot of people think you need to make a huge investment in time and resources to adopt agile development. While you can do this and certainly add value, there are productive ways to get started without all the religion. One approach is to break up the projects into smaller components and involve the users earlier in the development cycle.

Breaking up the project really means breaking up the program. It’s time to say goodbye to the monolith and the sooner the better. This is where the bulk of maintenance dollars lie. You the programs I am talking about. The ones that no one wants to open or modify because they a terrified of the repercussions. The ROI here is very hard to quantify in short order, but please refer back to the stripe study I mentioned earlier.

I discovered this purely by accident around 2004 when I was a development manager. One of my developers had a really good rapport with the principal user of an application she was developing. What they did was have a daily meeting as the user passed her desk in the morning to see the progress. The user gave her feedback immediately rather than at the end of the project and the developer was able to build on those changes as the application was being constructed. They limited themselves to 10 minute per day, no more, no less. Weekly they would meet with the manager for 10 minutes to show the weekly progress. The program was brought in on time and with no rework. It went live and the users started using it right away as it was exactly what they needed. 

I had no idea what she was doing at the time but this developer had organically stumbled upon several agile terms like incremental development, daily standup, collective ownership and more. The ROI here is obvious.

Final Thoughts

In the end, there are many ways to modernize IBM i applications. And, while modernization can seem scary, breaking out modernization efforts into small, incremental pieces like those described above can make it much more surmountable and still provide a good ROI for your company.

Need Help Modernizing Your IBM i Application? 

Zend can help! Our experienced professional services team can help you find the right modernization path and achieve it on your timeline. Contact our team today to learn more.

Contact Us

Additional Resources

• Case Study - AgVantage Software Modernizes Front-End System With ZendPHP on IBM i
• Blog - Exploring ZendHQ for IBM i
• Blog - Comparing ODBC vs. Db2 for IBM i
• Blog - Using Mezzio on IBM i
• Blog - Using MariaDB and PHP on IBM i
• Blog - IBM i Merlin and What it Means for PHP Teams
• Blog - Installing Zend Server on IBM i 
• Blog - Installing ZendPHP on IBM i