What to do about legacy applications? Modernize or migrate? Doing nothing really isn't an option.

I didn't want to write a part 2 of "Finding the New Breed of RPG Programmers." Think of this as an addendum. I say this because I'm not much of a developer. When I talk about development, it's at more of a strategic level. I won't comment on what tool to use versus another tool with regard to programming techniques because I just don't live in that world anymore, and my ignorance will show. When talking about development, my role is essentially to put the right resources on the required tasks and try to make it all work on time and on budget. I get to have the good-spirited (mostly) arguments with business unit directors and massage the user expectations. In the end, I'm an administrator at heart. I like making things go by loading/configuring, not coding, the former takes much less time and satisfies my short attention span.

Regarding "Finding the New Breed of RPG Programmers," I just want to make two quick points before moving on.

First, the feedback from that particular article was very positive and a little controversial—so much so that it triggered a good discussion on LinkedIn that veered into a feature-versus-feature comparison of languages and a dialogue about what constitutes a good IBM i developer. While not wading too far into the fray, I'll state that one comment is spot on in my book. A great trait of a good developer is that the bad managers dislike him and the good managers love him. I think that characteristic is not only for good developers but for anyone in a job where you need to be pushing the envelope. Those people are leaders. They're pioneers. They're not satisfied with status quo.

Second, there was a little poll where I posed this question: Did you learn RPG or IBM i (or predecessor technologies) as part of your college curriculum? It had 81 responses as of tonight [August 13, 2015]. On a quick count, about 25 percent of respondents had learned some form of RPG in college and only a fraction of those learned it on the AS/400 lineage. The point of that article has evidence after the fact. Better late than never, and I figured you should know about it.

To get on with the point of this article, I had a phone call this week from an applications administrator who has a similar job to mine with a similar infrastructure and wanted to pick my brain about a number of topics. Just two IT managers from different companies talking shop.

The topic turned to the dreaded words in modern IT: legacy applications.

So, Mr. Pitcher, what are you doing about them?

Like every question about intentions, it depends.

While I was quick to point out the great Colin Parris quote that "legacy means proven," we all must acknowledge that there is a much-needed trend to modernize applications. This modernization is not an end game but a strategic method. We must all be looking forward. We must be designing applications for the users of tomorrow with the tools we have today.

For decades, the company I work for relied heavily on the meat and potatoes of RPG and DB2. Currently, we're in the process of moving to a vendor-supported ERP that has some elements of RPG, yet all DB2 databases are now tables and all logical files are now views. In short, they're not DDS physical and logical files anymore. The bulk of the applications were written in Java. Most of our legacy applications for ERP are being modernized by an upfront purchase, rather than in-house development over time. Modernization isn't free, no matter which way you go.

But what about your custom Domino applications?

Ah, yes. Domino applications. Applications that complemented the ERP were generally built in Domino and many of those applications look a little long in the tooth by default. But they work. We have not taken the time or investment to go the Xpages route, IBM's suggested path to putting a more attractive front-end onto Domino applications. I've heard the uptake for Xpages described as "experimental" quite recently. It just hasn't taken off. The why really doesn't matter, but I'd assume it's because Xpages is far more a step from what Domino really is: staggeringly easy.

There are some striking similarities and some drastic differences between Domino applications and RPG applications. Domino applications are different compared to RPG applications because anyone can build one. That was its great strength, and some would argue it still is. You don't need to be a developer. Anyone can create a fully functional Domino application with minimal coding, or no code at all, by way of simple actions in a very short amount of time. It can scale to dramatic heights in terms of performance. And security? Forget about it. Record-level security was available many years ago with Domino. For user-built applications, just compare it with Microsoft Access, and Domino wins for simplicity, security, and scalability, especially if built by someone who knows how to build an application workflow. Arguably the biggest strength of Domino applications is backward-compatibility. If you built an application on Domino 6, you'd be 999 times out of 1000 able to run it on Domino 9. Sounds similar to IBM i applications written in RPG, right?

And as with the RPG modernization debate, Domino customers are also going through a modernization dilemma. As good as Domino is with backward-compatibility, its forward-compatibility is just the opposite. Likewise, as far as resourcing goes, it's the exact same argument. It's hard to find people, let alone young people, with Domino skill sets. There are no schools teaching Domino. Of course, if I did a poll similar to the aforementioned poll but asking Domino groups on LinkedIn, I imagine I'd get the same answer we got from the RPG and IBM i groups. They learned it on the job. Many of you bought Domino when it was announced on the AS/400 back in 1998 and just learned it.

What's the path for modernization of Domino applications? Do you make the investment in Xpages, or do you convert the application and valuable business logic to something else? Do you maintain the dreaded status quo?

For us, we made the decision to leverage IBM i for Domino applications. We already do in most respects as Domino works beautifully on IBM i. Vendor-supported Domino applications will remain on the Domino server. We pay support, and we must hold our vendors' feet to the fire in terms of demanding modernization. Let them put the modernization development effort into those. For our custom applications, we've decided to migrate away from the Domino NSF database to DB2 for i. For the business logic, we're using PHP. Our rationale is simple: the integrated DB2 database is the backbone of IBM i and therefore our business technology infrastructure. DB2 has shown a constant upward trend of modernization, allowing developers to take advantage of new features and improved scalability. The database is what counts. We have PHP skill in-house, which allows us to build modern, intuitive user interfaces, so we choose to leverage that skill. It so happens that there is an abundance of PHP developers in the overall IT community. Even if there wasn't, a Java programmer or even a free-form RPG programmer can read it. Let me rephrase that. We're building applications on IBM i that modern developers can read and write in the future.

But why? If Domino is so easy, why spend time converting to something else? While building business logic in Domino is easy, building an attractive and responsive user experience is not. This is where IBM has missed the mark, and this is a great place where they can do something positive. If there were an easy way to retain the business logic and build attractive, modern interfaces with the ease Domino customers are used to having, then we would be having our developers learn how to do it. Unfortunately, that doesn't appear to be on the horizon. And because the perceived uptake of Xpages isn't very high, I don't feel warm and fuzzy about spending resources converting everything to it. On that software side of IBM, products seem to come and stay or come and go. The future isn't quite as clear as it is on the systems side of IBM, where you can see POWER9 and POWER10 on the horizon, along with the next versions of IBM i.

There's really no right answer or wrong answer with regard to plans for legacy apps. You have to pick what's the best for your business. My colleague has a team of developers who've steadily upgraded their skills outside of Domino and RPG. Many different toolsets are under one roof. What do you do? You have to find that common ground. You have to inventory your resources and see what other people are doing. What do you see as a strategic application mainstay that will get you five or ten years down the line? For me, it's DB2. Especially if you use it in the modern SQL fashion. I think many of you would agree with that line of thinking. If not, please share your thoughts in the comments section of this article.

The tool you choose to drive data in and out is up to you. The safer bet is on more-open solutions, where communities are driving the development. Those tools tend to grow fast and organically with the times, while avoiding many of the aforementioned roadblocks along the way.