High Maintenance IBM i Application Therapy

July 8, 2013 Dan Burger

High maintenance is not what you want your IBM midrange applications to be. Unfortunately, that’s what happens in many instances. The neediness of the application is directly proportional to the age of the application. Neediness also grows alongside the size of the application. Big ol’ applications with hundreds of thousands and even millions of lines of code are very needy. It often takes a team of people just to keep them contented and predictable. And that sometimes makes other platforms look more attractive than they actually are.

Software maintenance, which occupies way more babysitting than it should, is really a form of on-going software development. That development is sometimes good, sometimes bad, and most times somewhere in between. (You could make the argument that if it’s not good, it’s bad, and there is no in between.) In IBM midrange shops, where complex applications tend to run complex businesses, software maintenance has been good enough to keep critical applications functioning for dozens of years. Longevity combined with reliability has made them a good business investment. Along with longevity, however, comes added complexity, even when development has been good. Longevity also added a lot of mystery, more so when development has been uneven and sometimes of dubious merit.

You may have heard that with age comes wisdom, but sometimes age arrives alone.

When companies are planning for the future, mysterious, high maintenance applications test the patience of executive managers who are not as enamored with the system as the programmers who have learned to live with it and are actually quite fond of it despite its sometimes snarky personality.

The RPG programmers can’t always explain the application in ways that satisfy management, but they remain steadfast in their confidence that IBM i platform and technology can continue to provide the best business value going forward. Proving that to itchy trigger finger executives is where the rubber meets the road. A possible long and painful migration to another platform, and a bloody rip and replace on the most important applications, hangs in the balance.

“People make decisions to get off the (IBM i) platform because they don’t know where they are going or where they are,” says Stuart Milligan, a veteran programmer who has seen the train wreck of old and ill-maintained programs. “They should be asking for metrics that map the system and aggregate the parts. Before decisions get made they should identify where the complexities are and where the heavy usage is.”

“The thought processes for people who don’t know what they have can move very quickly to ‘I will have to replace this.’ That reaction does not taken into account the complexity of the problem. When you look at this in a modern way, you see that whatever you do, it’s going to be difficult. It’s naïve to think that system replacement is going be the easy way out, despite what you might be hearing from Microsoft or Oracle.”

Milligan has seen this play out numerous times. He is vice president of special projects at Databorough, which puts him in the same boat with companies fishing for answers to questions about their legacy RPG and COBOL applications. He says the most frequent questions are: What have I got and what is the business value?

The first thing skeptical readers are going to note is that Milligan has his own interest at heart when feeding the media information that helps sell his software. I know. I’m a pretty good skeptic myself. I still think his views into legacy application complexities and the dark side of the application moon are insightful and an accurate depiction of one of the tough IT decisions organizations have to make.

We can all agree there are obese IBM i applications in use that can still run a mile, but are not a threat to break any records getting there. Often they cause great frustration in companies that are in a competitive race to win new business and keep the business they have.

“There are two camps interested in unraveling the secrets that exist inside legacy applications,” Milligan says. “One camp is interested in being rid of the old applications and the IBM i platform as well. But they want to take business value with them that can be used as the app disappears into SAP or Oracle or Java. Then there are the people who have yet to decide what the next step will be and are not in a hurry to change, but they want to figure out what is the best move.”

The discovery process, which Milligan’s software company automates, leads to identifying pain points resulting from overly complex and poorly written code.

The goal of the discovery process is to improve maintenance programming for legacy systems by revealing the mysteries and increasing developers’ comprehension of unfamiliar programs. Conquering the unknown brings the benefits of maintaining programs in less time and with fewer mistakes. More productivity from fewer people is the kind of statement that gets the attention of executives.

The benefits are bigger than that for companies interested in integration of IBM data and applications with other platforms based on other programming languages. But determining where to start, what to do, and where the business benefits are should be the first priority in order to plan effectively for the future.

It’s the “knowledge exposure,” as Milligan calls it, that goes beyond the RPG development team that heightens the business value.

The most important recipient of this knowledge is management because a better understanding of mission critical applications reveals how a business actually runs and is dependent on the existing system. It allows actual comparisons to be made with the existing system and what might be picked as a migration system.

When that comparison is made, Milligan says, the decision to continue to use what is in place and improve upon it looks much better. He estimates 10 percent of the companies doing business with Databorough make a decision that the application is too much of a mess and a rewrite is necessary. That includes companies with individuals or teams that go into it wanting to prove migration and a new application is the only answer. The visibility allows people to understand the problem and fix it. Maybe 10 percent decide it’s too much trouble to fix.

“When people are talking business assets and not technology, it becomes a real dialog,” Milligan says. “The fear of the unknown is removed from the decision making. When the knowledge base is spread around the group rather than just within a pool of RPG programmers, more people have a stake in maintaining the business application. You need a common language (the language of business) to gain an understanding of the value of the application. When someone says something is stupid, someone else can say, ‘No, it’s not. Look at the data model. There’s value there that you can’t write with all your Java qualifications in one year.’ Getting to know the application creates a transparency or a visibility.

“What is needed is a more collaborative approach. You need to get away from the idea that the IBM i system is this black box in the corner that is guarded by strange wizards with long beards and gray hair who wave a wand over it.”

Debating programming languages is a sideshow. The focus when the technical people talk should be on business rules and data models. There is a universal respect among most programmers for a massive program that has evolved over many years. There will no doubt be gripes that it has architecturally eroded and what you have is not what anyone would write from scratch today, but the value can’t be denied once everyone understands how it works.