The default situation for buying an application development tool is when you are building a system from the ground up. Nothing out there suits your business, so you need to write your own from scratch. Hello, Google! Another is when you have to add a new application, one whose features and functions are different enough from your existing systems as to require a new way to develop code. Maybe you need to add browser-based order entry to your existing green-screen business suite.
However, given the potential productivity benefits of the new generation of tools, it may be to your advantage to think about moving some or all of your development to new tooling. But can you really maintain existing applications with these new products?
The answer depends on what you want to do and which tool you want to do it with. Tooling ranges from Integrated Development Environments (IDEs) such as WebSphere Development Studio Client for System i (WDSC) to complete application development (AD) suites from vendors such as LANSA, BCD, or CA. In between, you'll find application generators and refacing tools. (Some vendors will even try to convince you to migrate your mission-critical applications off of the System i onto Windows. I believe Dante designated the Fourth Circle of Hell for those folks.)
As you might guess, each of these options has a different scope, and which one suits you best depends on your needs. Let me move from the finest grain on down to the easiest.
Application Development Suites
The goal of AD suites is to allow you to define repositories of business rules that can then be used to quickly build powerful applications. Unlike the more data-centric 4GL products of the '90s (some of you might remember the AS/SET tool from System Software Associates), the newer generation of tools is designed to help you create business rules and then build applications from there.
The benefit of this sort of approach is that the business rules should be transparent to the user interface; with the right tooling, you ought to be able to develop applications that work with Web browsers as easily as with thick clients, cell phones, or even green-screens. You would define your business rules once and then be able to concentrate on building the sort of interface features that your users need. And for ground-up application design, these tools provide huge benefits.
However, if you already have applications, it's not so easy to take advantage of these tools. The biggest hurdle facing existing shops is encapsulating existing business rules. Various vendors claim to have tools that "extract" business rules from existing green screen applications, but to my knowledge there isn't a single product available that actually succeeds at this to any significant degree. There are only two ways to do this: wrapper existing green-screen applications and in effect emulate keystrokes or else actually go into the RPG code and try to separate database logic from screen I/O without introducing any errors. The former has serious performance implications, while the latter is nearly impossible to do using programmatic techniques.
Not only that, but there is the not-so-minor issue of whether or not the vendor's business rules repository is flexible enough to handle your more-complex business rules. To take a very simplistic example, let's say a vendor's repository allows for only 13 accounting periods, and you have 14. No matter what you do, your business rules won't fit into the vendor's repository. So you need to perform a thorough examination of the vendor's framework to make sure your business fits into it.
Note that this is usually much more of an issue for packaged software than application development (AD) tools, but even AD tools have limitations. You need to spend some time mapping your requirements to the tool's capabilities before you even embark on a migration.
Once you do have a repository in place, life is wonderful, but getting your business rules into the repository is the biggest cost for this environment. In reality, you wouldn't maintain your existing applications; you would actually migrate your applications into the repository of the tool.
Application Generation Tools
Application generation tools are a bit different. The primary purpose of these tools is to build applications from predefined templates. Typically, these tools have a number of templates available. For example, a CRUD (Create, Read, Update, Delete) template is used to quickly build a file maintenance application. Depending on the tool, you can start at the file level by defining the fields in a new file, which the tool will then build for you, or you can specify an existing file and the tool will use that as its starting point.
These are more like expert systems in that the vendor has encapsulated its experience and expertise in program design into a set of coding patterns that are then extended when you provide information about your application. Typically, the business rules are simple and predefined, although the more advanced tools have some sort of exit points where you can insert your own custom logic. By and large, though, these tools are not intended to build complex, data-driven business applications, such as pricing or order processing. These tools are better suited to providing the store-front order-entry capabilities of a Web store and then allowing the back-end processing to actually handle the data. Another place these products excel is at designing standard data mining and inquiry applications, with various levels of data manipulation and drill-down capabilities.
Because of this, a good application generation tool could be a huge asset to an existing application. If it allows easy access to existing data files and is extensible, then it can probably be made to work with your existing applications relatively easily. The biggest question then is whether or not the user interface capabilities of the tool are enough for all of your business needs.
Typically, these tools have relatively hard-coded user interfaces. Because of the nature of a template-driven design, you usually have little say over the final product other than simple cosmetics (logos, colors, and the like). For example, a CRUD application may present data in a table, with each row having a set of icons that represent add, update, and delete. You wouldn't be able to change that basic capability. For example, you might instead want to have a checkbox on each record and then a button on the bottom of the panel to allow you to delete a whole set of records at once. With an application generator, you pretty much get whatever the vendor gives you. It's rare to find a tool like this with completely extensible templates.
If, though, the basic application style meets your requirements, then an application generator is likely to be one of the fastest methods to extend your application. The only question then is whether the tool has the capability of interacting seamlessly with other applications. For example, let's say you wanted to write your own application and combine it with the generated code. Can you somehow pass information between the two applications (in a browser, this might be done by passing parameters in the URL)? If the tool provides this level of integration with external applications, it means you can add your own code regardless of the capabilities of the supplied templates, which makes the tool much more flexible.
Integrated Development Environments (IDEs)
The last category of tools are the IDEs. IDEs are not application development tools like the previous tools. Typically, IDEs provide little in the way of application-building expertise (although that depends on the IDE, and I'll touch on that in a moment). Generally speaking, IDEs provide you with a workbench from which you can easily develop—and even more importantly, debug—your applications. The best IDEs provide powerful source-level debugging capabilities and excellent GUI tools to make it easy to develop applications.
One of the long-time leaders in this category has been Microsoft and its Visual Studio tools. Going back to the early days of Visual Basic, Microsoft tried to make it easier and easier for even non-programmers to build applications. With lots of point-and-click capabilities and extensive help support and online examples, it was easy for even hobbiests to put together working software. This capability has affected many tool vendors and has led to entire projects such as Eclipse, where the focus was on a simple, consistent interface that can be extended to provide all manner of development capabilities.
The pinnacle of that design today is WDSC, which is a complete end-to-end development tool that allows you to maintain and debug all the components of a multi-platform, multi-tiered application. The important part of that sentence is the fact that you can use the IDE to maintain your exiting code. You don't even have to want to modernize your application in order to take advantage of the features of WDSC; for example, a large screen allows you to have 60 lines each of four different source files all visible at the same time. That's a huge improvement over anything you'd be able to accomplish in a green-screen environment.
At the same time, WDSC allows you to build Web applications from scratch, using industry-standard languages such as Java, complete System i–centric designs such as RPG CGI, or multi-tiered architectures using a JavaServer Pages (JSP) front-end connected to RPG business logic. WDSC includes a powerful WYSIWYG HTML and JSP editor with extensive drag-and-drop design capabilities and a complete snippet library. The Site Designer is a Web site layout tool with complete template-driven design and the ability to easily apply different templates to different portions of your Web site; it also provides a consistent auto-generated navigation capability. The Cascading Style Sheet (CSS) editor is perhaps the best available today. With its integrated WebSphere Test Environment and the ability to set breakpoints on both the workstation and the host, WDSC is pretty much the only IDE that can allow you to test multi-platform, multi-language designs from end to end.
And it's a good thing that WDSC is such a great tool, because frankly it's the only thing we have. All other IDEs are targeted at markets other than the System i, ranging from Microsoft's Windows focus to the slew of Java-related IDEs to even the handful of mainframe development tools. No other tool targets the System i, but that's OK, because ours is the best.
One other point about WDSC: WDSC is a Rational tool. That is, it's based on the Rational AD product suite. Because of that, WDSC is compatible with something called the Rational Business Developer, which is tooling for the EGL language. You may not have heard about EGL yet, but you will over the coming months and years because IBM is really focusing on it. EGL is a 4GL that is currently highly data-centric, but the new version has a lot of application-generation capabilities as well as some powerful user-interface features, so you may want to take a look at the tool when you get a chance. IBM is positioning this product squarely as an application development suite, so if you're looking to create new applications, IBM would want you to take a serious look at EGL.
From my perspective as a System i developer, I'm far more intrigued by the capabilities as a remarkably easy way to develop browser pages that can interact with RPG business logic. I've written a number of articles on this technique; with just a few lines of EGL code, you can take the fields from a JSP page (actually a JavaServer Faces or JSF page) and pass them in a data structure to an RPG program to perform business logic. This capability, which I call "SDA for the browser" (much to the chagrin of the EGL developers) is exactly what System i developers need to move from the green-screen to the Web.
The only problem is that as of WDSC Version 7, IBM unbundled EGL from the base WDCS package. System i developers can only get it as an upgrade to WDSC Version 6 until June 30; after that, it becomes a separately charged product. So if you want to see what this language has to offer, you have to jump on the opportunity immediately.
Other Application Enhancements
One other quick boost that you might consider is a Web-enablement tool. Various refacing strategies exist that allow you to put a browser interface onto your existing green-screen applications. However, since these tools don't really have anything to do with maintaining your applications (they are an additional step after you maintain the green-screen application), they fall outside of the scope of this article.
The reason I bring this up, though, is that a Web-enablement tool may afford you some tactical breathing space as you begin your strategic deployment initiative. Tools such as WebFacing can give you a new UI to present to your users as you identify the best tool for your long-range development and begin to deploy it. Disclosure: I sell such a tool, so take this paragraph with the appropriate grain of salt.
In any case, the new tools available today can help you to maintain your existing applications, whether or not you need to make major enhancements. Even if your primarily development strategy right now is "if it ain't broke, don't fix it," the tools today will still make it easier to fix things when they are broken. The question is not whether you should use new tools, but which one you should use.