IBM i Code Base Is Elderly, The System Is Not
February 19, 2018 Dan Burger
Pain management. It’s good for your overall health and good for your business. Think of your IT strategy as ongoing pain control. If you are suffering with chronic pain, amputation (migration to another system) is probably not your best choice.
“People don’t realize how painful some of the legacy systems are,” Mike Pavlak says. “They are complex and tightly wound, which is both a blessing and a curse. They often perform like lightning – transactions fly through the system – but developers spend a lot of time on maintenance. There’s a certain amount of truth to the statement that too much time doing maintenance prevents new development and modernization.”
When organizations are no longer capable of quickly responding to the changing needs of business, it’s typically a sign that an “elderly” code base has become unmaintainable, says Jon Paris. An infusion of modern skills and modern tools, he believes, will prove the IBM i can do modern computing workloads.
“The problem is not with the platform. It’s with the applications,” Paul Tuohy suggests. “The problems with old apps get rolled over to the platform.” (Making it guilty by association).
Tuohy, Paris and Pavlak let their feelings be known to IT Jungle in a telephone interview last week. All three will be presenting technical sessions at the RPG & DB2 Summit scheduled March 20 through 22 in Dallas, Texas.
“We tell attendees at the Summit to look at everything their systems can do. We encourage people to always say ‘yes’ when someone in the organization makes an IT request. The biggest hurdle developers have is realizing that all things are possible,” Tuohy says.
“The biggest difference between Windows developers and IBM i developers is that we’re too honest,” Paris adds in his typical half-joking style. “A Windows or Unix developer will always say ‘yes’ to a request. We tend to say, ‘I’m not sure.’ I tell people, ‘We need to become better liars.'”
Being a liar isn’t Paris’ point. Being a better programmer with the confidence to take on modern, business-driven projects is. (I checked the session grid for the upcoming Summit and there is no session called How To Become a Better Liar.)
Optimizing application development and maintenance can cut costs, some say by as much as 50 percent by eliminating legacy applications. Eliminating doesn’t mean migrating. It means modernizing. Modularizing monolithic programs will reduce maintenance and save the corresponding cost relative to high-maintenance programs. Migrating often takes you to a place you don’t want to go at a price you don’t need to pay. Modernizing allows companies to keep applications that are customized to their business rather than customizing the business to suit the software.
“I can’t remember ever hearing of a modernization project costing more than what a migration would have cost. I can’t remember hearing of a migration plan that came in less than two times the planned budget. Seven, eight, nine times budget is not uncommon,” Paris says.
For many shops maintenance and development have a substantial amount of overlap. In a strict sense, maintenance is limited to fixing bugs and perhaps modifying functionality. Development is, in theory, a process of creating functionality that was never available before, with an emphasis on new projects. Enhancements to existing projects is the grey area that come call maintenance and others call development.
Less application maintenance doesn’t necessarily equate to more time for new development and modernization projects. But it could if development is a priority.
“IT organizations may stand at different points on the spectrum, but all of the CIOs in the room (at the IT CIO roundtable during the Summit last fall) were there to help their staffs deliver cost-effective technology that provides a competitive edge,” Paris says. “The IBM i is brilliant at that. The trick is to get buy-in from the business to invest in new skills and the resources needed to undo years of tight efficiency and neglect in terms of code refactoring.”
With the cost of migrations being multiples of the cost of modernizing, there’s more than enough room for investments in new skills and tools. Tuohy suggests the IBM i team prepare a modernization bid and a plan that includes the increased staffing that come with migrations. One of his sessions at the Summit includes information on how to justify modernization. The session is mostly practical requirements and tooling for modernization projects.
Pavlak specializes in “scoping” projects and determining reasonably accurate budgets. He says it’s not unusual for companies to run 80 percent of their business applications on the IBM i platform with a staff that is one-quarter the size of the staff that handles the other 20 percent.
With regard to upgrading skills, the Summit session agenda is targeted for IBM i developers and database engineers highlighted by modern tips and techniques that can be used immediately to modularize code and improve the use of RPG, Db2, SQL, web/mobile technologies, web services, ILE, open source, and development tools.