With all the options available, are you in danger of being blinded by application development science?

RPG is no longer a standalone language. Gone are the days of learning RPG alone; you have to interface with the larger IT environment. If you read forums or mailing lists or blogs in the i community, you'll find an almost endless variety of options for exposing your RPG business logic, ranging from the latest tools, like EGL, to some of the more venerable options, such as Net.Data. If you're not careful, you could find yourself falling down the technology rabbit hole, chasing options like PHP or even Python.

Part of this might reflect a trend of choosing technology for its own sake. While that's been a phenomenon in the larger IT world for some time, it's only recently become evident in the i community. It's no coincidence that as the i evolved into the most open platform available, these arguments became more numerous. Nowadays, you'll find people taking stands based not on business requirements but instead on perceived benefits of a given language. This is a road fraught with peril; what may make a language a good fit for one application may be exactly the thing that makes it a bad choice for another. This article will help you identify what's really important.

So What's an RPG Developer Supposed to Do?

The most important thing is to identify your business requirements. Seen from the correct perspective, even technical issues become business requirements. Let's say one IDE has a better visual editor than another. Well, how much will a visual editor actually save you in development time? Are the programmers in your environment visually oriented, or are they die-hard source-code editors?

If you attack the question from that angle, it becomes easier to identify the development tools that best fit your company. And while I can't tell you what's best for your company--nobody can unless they actually know what your company does and how your development process works--I can list some examples of business requirements that can point you down the road to making your own choices.

User Interface

User interface is a very good first choice for identifying business requirements. That's because while it seems like an easy question, if you spend some time carefully considering the question, you might be surprised at the answer.

As I said, the question seems easy; nearly everybody wants a "Web interface." But that's sort of an amorphous need, kind of like "food." Many different kinds of food will sustain you, but there's a big difference between pot roast and Peking duck, and which you choose will depend a lot on your own skills and the time at hand. In the case of user interface, you need to think about several things.

First, are you really creating Web applications that need RPG business logic or just a browser interface to some of your data? Are you going to create an intranet site so that your internal users can access business functions? Or will your vendors and clients be accessing this site? And more importantly, will your business depend on how that site looks? Will your Web presence be used to drive business to your site?

These are important questions because they drive the interface language requirements. Today, a simple browser interface can be implemented in nearly any technology. You can use Net.Data, the old standby that is basically included free with the i platform, to create nice Web pages by learning just some basic HTML and the simple Net.Data macro language. But if you want to create a powerful, rich interface that can be honestly termed a "Web 2.0" application, you need to learn a lot more about the new JavaScript frameworks and learn how to adapt them to your environment.

External Community

I've seen a lot about this lately, probably because of the introduction of PHP into the mix. As RPG programmers, we're not used to dozens of forums with thousands of users. And if you need a huge community of developers to help you design and develop your applications, using a language like Java or PHP with a vast worldwide acceptance is going to appeal to you.

But beware the hype around this particular point. There's been a particularly interesting debate on the issue of PHP's community. That's due to the dual nature of the language. Originally designed as solely an HTML scripting engine, PHP has evolved significantly over the years, with the division between PHP 4 and PHP 5 being particularly dramatic. The situation is quite similar to the difference between RPG III and RPG IV; you can do most of what you did in PHP 4 in PHP 5, but if you want to write real business applications, you pretty much have to use PHP 5.

The problem is that the vast majority of code and support in the online community is still based on PHP 4. So while it's true that a large community does exist, that community may not be a big resource for a company that's planning on using the language for advanced application development. And the segment of that community that's dedicated to the i platform is smaller still.

And in the long run, you have to decide how much of your business will depend on free online support. Personally, I think this particular issue may get a little too much emphasis. Because while I live on the bleeding edge of technology and often find myself relying on the kindness of strangers, are you really putting technologies you don't know into production? Or are you occasionally running proof-of-concept projects to determine the viability of a given approach and then carefully integrating that into your development environment? The former requires a lot of time on the Web looking for help, while the latter is more about short bursts of focused learning.

Your Staff

This may be one of the more telling points. It's perhaps the biggest hammer in the belt, and it's the one that seems to really frighten a lot of technology managers. There's no denying the fact that the RPG community is graying; all I have to do is look in the mirror to see that. It's getting harder to find good RPG help.

But the more pressing question is what kind of in-house expertise you have for your Web interface, if indeed you're going in that direction. If you are primarily a Microsoft .Net shop, then the writing may be on the wall for you already. .Net is a solid, viable platform option whose primary downsides are lock-in to Microsoft and the price per server. If you're already running Microsoft servers in your shop, then the incremental cost may not be as challenging.

I Don't See an Answer Here

I'm sure you've noticed that I haven't actually given you a recommendation. That's because I can't. As I noted a little earlier, nobody can really tell you what's best for your company unless they really know your company.

But let me walk you through a couple of scenarios.

Scenario 1

You're primarily a green-screen shop with a large custom application. You need to give a few of your users browser access to some data, but you don't have a lot of in-house expertise. You're not worried about strategic direction today; you just need to make some data available.

Well, in this case, Net.Data is actually not a bad choice. It takes minutes to get your first Net.Data application running, and you can be serving Web pages containing data from your database almost immediately. Not bad, provided you understand this is essentially throw-away work if you decide on a more ambitious Web interface later.

Scenario 2

You're a pretty savvy RPG shop that's gone a long way down the ILE path. You know how and why to write modular programs that separate user interface and business logic, and you've already written a few browser applications using JSP and the response has been good. Your trading partners want you to expose some of your processes as Web services, and you need an online order application that looks as good as anything available but still interfaces with your back-end systems.

Unfortunately, the Java learning curve has been steep, and you aren't nearly as far along as you'd like to be. You're out of education bandwidth as it is, and you haven't even begun to research the Web 2.0 technologies.

In this case, you might seriously consider EGL. Most of the work you've done in JSP can be transferred to EGL's JSF interface, and you can create Web services with just a few lines of code. Those services will call the business modules you've already written, and you can focus your development efforts on the new Rich UI technology that will allow you to write Web applications using the latest frameworks, such as Dojo, without having to learn nearly as much of the plumbing.

How Do I Decide?

It's a big question, and you can get a lot of conflicting input. But if you are able to step back from the language wars and identify your business requirements, I think that the choices become a lot clearer. Hopefully, this article helped you take that step.