The IBM i Roadmap Leads To A Familiar Place
March 19, 2018 Dan Burger
Reeve Fritchman is working on project that he believes might tell the future of the IBM i. It’s a complex mainframe-to-IBM i migration. The core applications were written by an in-house team of developers, many who are still on the staff but on the verge of retirement. The hardware maintenance is expensive, and a hardware upgrade would be absurdly expensive. The bills from CA for automation software are staggering.
“The demise of the mainframe in small to medium size shops could be a precursor of what will happen in the AS/400 environment – fewer skilled workers, expensive, and better technology available on alternative platforms,” Fritchman says.
Fritchman knows the sights, the smells and the sounds of enterprise IT. He was a systems engineer in IBM’s General Systems Division when the System/38 was born and his understanding of complex information technologies began. He left IBM in the mid-1980s to develop a System/38-based workflow application for the trucking industry. That software evolved into LTL/400 with the advent of the AS/400. That product remains in service today after numerous enhancements and is running on Power Systems featuring IBM i.
Fritchman and I spoke last week on the topic of the IBM i roadmap and the IBM i community. He still refers to the system as the AS/400 – perhaps as a marker of the day the music died – so get used to it. I don’t think Fritchman is going to change his habits or his opinions. His opinions are often loaded with skepticism. But he doesn’t paint everything black and just because he doesn’t toe the line doesn’t make him a bad guy.
“What we are seeing with the maturing of the AS/400 and the aging workforce is technological Darwinism,” he says. “It doesn’t mean the AS/400 won’t do the job, because I believe it does. But I think the cards are not stacked in its favor.”
“I suppose it’s possible that IBM has some gigantic moonshot program running somewhere, but I’m not confident that’s the case. I think IBM is looking at the AS/400 market from a purely economic standpoint. There’s a graph in somebody’s office that, when the lines cross, the announcement letters are going to get drafted by the lawyers.”
On the plus side, Fritchman lists several IBM i enhancements that he believes are important to the platform’s success: RDi support for Mac, support for Linux and PHP, terrific hardware and database technologies, and capabilities that relate to big data and artificial intelligence.
“But the real issue is whether the IT executives in their 50s and 60s are ready to take on a Holy War to save the AS/400 – repurposing it by investing in newer software technologies,” he says, sounding doubtful that such a thing would occur. We are still stuck in the day-to-day effort of getting the job done. We have to decide how can any platform help a business be efficient. That’s a factor that drives a lot of application development, although it’s not really a technology issue. It’s a management problem that comes down to people and business choices.”
The IBM i chief architect Steve Will wouldn’t disagree with that. He’s been on a crusade to get more IBM i customers to invest in training people in modern technologies and to reach executive management with the message that IBM i is modern, but it is being underutilized. Many of the tools that were introduced when the system was called the AS/400 are still being used today. The message “Look what i can do for you” is being delivered, but not in a big way. The best description for how the message is being received is “lukewarm.”
“We become mired in so many areas,” Fritchman says.
As others have pointed out on numerous occasions, a better outcome for IBM i could have been assured if IBM had played its cards differently, but the same could be said for the customer base, which remained comfortable with 1990s technology for too long.
Fritchman agrees.
“We – IBM and its AS/400 customers – were successful up to a point, then we stopped being successful because of limitations on the platform and within the community itself,” he observes. “One of the reasons the AS/400 has not succeeded is because most of the early programmers never broadened their technology view and embraced other technologies is a failure by the community because we haven’t pushed IBM hard enough. We should have pushed them harder on more sophisticated technologies instead of IBM feeding us little bits of RPG enhancements.”
“The community has succeeded from a tactical standpoint,” he continues. “We got the job done. But on the other hand, if an organization has never refactored its code and is still running really old RPG, it is incredibly difficult to maintain and modernize because there are so few programming opportunities to take advantage of. Those organizations that have not refactored their code may be stuck and unable to upgrade or modernize their systems because the cost of upgrading will be so high it will be impractical.”
By Fritchman’s estimation, moving a core application off an IBM i system at a $100-million company with 100 or so users on a busy system, would likely cost several million dollars. That’s a financial hit many businesses cannot take.
“Many of the early programmers had coding skills but were short on programming skills and they painted themselves into a corner of technical debt. Their work makes it hard to update, hard to modify, and hard to provide business value to the stakeholders in a company,” he says.
There are IBM i-based companies modernizing their way into the ball game. It’s being done, but mostly in an incremental fashion. The migrations, by comparison, tend to be an “all in” bet with outcomes that fall short of success. Either way, the technical debt that shops carry needs to be diminished in a way that does the least harm to the business and the budget.
RELATED STORIES
Reader Feedback On IBM i Strategy
IBM i Strategy: Technology Choices And The Vendor Ecosystem
Investment And Integration Indicators For IBM i
The shops that stayed stuck in inefficient RPG III is what killed the IBM i. I turned down multiple job postions around 2007-2008 because they used RPG III and had no intention of moving away from it to a more current version. IBM should have pulled the plug on RPG !!! after a decent interval when they dropped support in 1992. I have worked with IBM systems since S/3 and kept myself current in RPG, but finally threw up my hands and now work in a Linux environment.