Not So Hard To See i To i
May 1, 2017 Dan Burger
You’re not the only oyster in the stew. The IBM i community is a combination of unique ingredients that make over-generalizations risky business. The landscape looks different depending on whether your view is from the valley or the mountain. That’s why I like to talk with people with experiences that are different from my own. We learn from different perspectives.
Mike Scanlon has worked most of his 30-plus years in the IT business in eastern Iowa. He came out of college with a software development education that emphasized COBOL. His career path eventually led to a software development job with an IBM business partner in the life insurance field, which is where he met the IBM AS/400 for the first time. He’s been working with the IBM midrange platform – AS/400, iSeries, System i, and IBM i – since the early 1990s.
Our discussion began with IT spending and how most businesses consider IT a cost of doing business rather than a source for creating revenue.
I’ve seen surveys that indicate businesses spend between 1 percent and 10 percent of their annual revenue on technology. At the low end of that range is manufacturing and retail and at the high end we find finance and health care. The costs include hardware, software and training. Much of this is ongoing, although a lot of companies are cheap when it comes to training. I believe value propositions are rarely considered. So, savings attributed to time-saving technology are not being considered beyond an assumption that they exist. And revenue lost by not having automated systems is well below the awareness level of most decision makers.
When Scanlon worked at Nordstrom, he recalls a two- to three-year period when the company tried to turn IT into a revenue center, by creating charge-backs to the various departments. It was marginally successful for a while until the top managers at the divisional level started outsourcing IT to reduce costs.
“That caused a host of problems,” Scanlon says. “One of them being the loss of intellectual property. And another was the loss of good IT professionals who saw what was happening and began leaving the company and taking jobs at other companies.”
It’s impossible to know how often this scenario occurred at companies regardless of the IT systems in place, but it’s my guess the success stories are rare. The silver lining might be that awareness of IT value might be increased, which could lead to certain IT workloads being outsourced when it makes sense to do that. Freeing IT staff to do more important work is probably a cost reduction and a workflow efficiency that could result in increased revenue.
As outsourcing workloads led the conversation toward the cloud, Scanlon pointed out his early experiences that pre-dated the now ubiquitous cloud terminology. Before there was a cloud and software as a service, there were application service providers (ASPs). Same idea, perhaps a bit ahead of its time, but saddled with a boring name.
Scanlon developed software for a life insurance company running on the AS/400.
“We developed systems that could be run on premise or on hosted systems that were accessed remotely. In the mid-1990s, those systems ran in our data center in Cedar Rapids, Iowa, in partitions set up for each customer on our large-scale IBM AS/400 servers. We had the full line of software development, quality assurance, regression testing – all the pieces of the software development lifecycle on behalf of the client,” he said.
Approximately 10 percent of the software customers chose the hosted option and it tended to be smaller companies that saw it as a strategy to avoid the cost of an AS/400 system., Scanlon estimated. In this case, they wanted off their expensive legacy mainframe systems and were attracted to the functionality in the life insurance applications designed to run on the AS/400.
“About half of the banking companies that ran on mainframes, after seeing what the AS/400 could do with the life insurance applications, moved their banking apps to the AS/400 as well,” Scanlon said. This was at a time when the rules that separated banking and insurance dissolved, which created a great demand by banks to acquire insurance applications.
Despite the name change from the blunt application service provider to the much sharper cloud provider, enterprise computing remains hesitant. Data analytics and cognitive computing are the main attractions, but the enterprise level gold rush has yet to materialize. IBM, its partners, and its competitors are elbowing their way to better visibility, while touting the unproven claims of money savings and competitive advantage. It’s not just the legacy last-adopters who are reluctant when it comes to the cloud, even though the hypesters make it seem that way.
Of greater importance to the proud to be legacy contingent are the decisions to upgrade neglected applications and databases and plans for how to do it. This, too, is not a new dilemma. There are a lot of shops that have been noodling this idea for a decade or more.
Scanlon helped a manufacturer of belts, hoses, and cut & molded products called Apache develop a strategic plan involving the migration of applications written in legacy RPG and COBOL.
“One of the things I did was to look into Zen Server and PHP. I looked at other options as well, but it came down to Java and PHP. I picked PHP and installed PASE environments on the AS/400 for a couple reasons,” he said. “PHP is more like a process-based, modular language and it was a better fit for me and our developers. PHP is also a language skill that many young programmers have. And the skills they have were somewhat transferable to where I wanted our strategic plan to go.”
Apache had vendor-packaged software that was recently upgraded with modern RPG code for the core application and a Java-based front end. To gain additional functionality and include the custom work that Apache provided for its customers, PHP was used. And because the ERP vendor did not convert all its green screens to Java, the Apache development team created a path forward using BCD Presto to create a GUI and a new menu structure for the green screens. That added capabilities some users had been requesting for many years, Scanlon said. At the same time, there were in-house applications written in older RPG that were being upgraded to ILE, so they were interchangeable with new technologies.
“We sometimes built extension files on the core ERP files from the vendor because we wanted to track additional attributes and more details in the transactions. All these extensions had graphical user interfaces created with Presto. It kept the backend core logic within RPG, but the replacement of the DDS files was done with the Presto app,” Scanlon said.
Because of Scanlon’s use of PHP, that led our conversation into the topic of open source development and IBM’s efforts in expanding open source options. It’s clear that the IBM i development team is interested in providing customers with options for application development that go beyond RPG, Java, and PHP. Open source skills are becoming much more common, especially with young developers who often have multiple language skills. And making development decisions based on the skills available in house is generally a sound choice.
“The companies with IBM i systems in place should be thinking about the skills they can hire,” Scanlon says.
“I’ve been on the advisory council for a local community college in Cedar Rapids for 20 years. The question used to be about teaching RPG II, III or IV? Then Java was a consideration. Now some of the companies on the advisory board are making sure the college is teaching subjects like Node.js, Ruby on Rails, Python, and Perl. I don’t see a lot of businesses spending a lot of time in those languages today, but the trend is in that direction.
“Most business people don’t give a flip about which technology stack they are using. They just want to be able to readily hire a workforce that will keep the business moving forward.”
There are still shops doing a lot of new development work using modern RPG. Both Scanlon and I agree that from a technical perspective, there’s nothing wrong with doing all your modern development work in RPG. But where that falls short is conveying to business leaders that it is a modern viable solution. There are too many boardroom members with the opinion that the system needs to be replaced. The board needs to be assured that keeping RPG and being modern can be achieved and the business does not have to throw away valuable business logic to get a modern system.
“I think it will be harder to find RPG skills in the future despite the similarities with other programs,” Scanlon says. “There will be a training and education element, but good coders have the skill sets to learn new languages. They can learn modern RPG and the Rational tools.
RELATED STORIES
Getting Offensive With The Legacy Label
IT Spending And Staffing Show The Effects Of Managed Services
The Hybrid Cloud Questions IBM i Shops Should Be Asking
IBM Preaches Cognitive, Cloud, And IT Consumption
IBM i Shops Seeking More Services
Is the IBM i Skills Shortage Accelerating Platform Migrations?
>The board needs to be assured that keeping RPG and being modern can be achieved and the business does not have to throw away valuable business logic to get a modern system.
Whether RPG is modern is a lesser problem. The much bigger problem is the lack of open source software available for RPG programmers to help their businesses move forward at the same pace as those using Ruby, Node.js, PHP, Python, etc; all of which have an insane amount of libraries to choose from to get business done faster. In short, it’s our lack of RPG community that’s at issue. We ~could~ work really hard to rebirth the RPG community in hopes of usurping others, or we could try one of the open source languages and put it to the test. I did, and the open source languages won (and that’s not necessarily because I wanted them to, I wanted RPG to win).