"Ripeness is all." That's what Shakespeare's King Lear says when asked what's the most important thing. He was thinking of people, but the same could be applied to ideas — and in the case of IBM Rational Rapid Developer (RRD), products. This product isn't new (originally developed by NeuVis Inc. and further developed by Rational Software Corp., which is now part of IBM, this latest incarnation is the product's fifth release). Its fundamental operation is what we used to call in the old days a code generator. Its raison d'etre is to help inexperienced programmers create sophisticated software applications — arguably the Holy Grail of application development since the dawn of coding.

What RRD v2003 brings to the effort is an approach that IBM calls "architected rapid application development." The approach starts with Java (J2EE, JSP, and so on.), combines it with several Web standards (such as XML and SOAP), adds a very large dose of software development modeling (mostly UML in origin), and mixes it all into a model-oriented IDE designed to minimize the amount of programmer coding (see Figure 2).

It isn't a "turn the crank and get a perfect n-tiered Web application" kind of code generator — if there ever could be — but the approach has been improved to the point where enterprise shops interested in quicker and better application development really need to give it a hard look. In the emerging class of IDEs using a model-driven architecture (MDA), RRD is a relatively polished pioneer, which may be one reason why both IBM and Microsoft competed vigorously to acquire Rational Software.

The Rational Way

For years, Rational Software developed products tailored to the enterprise-level need for software architectures, frameworks, and modeling. As you would expect, RRD fits smoothly into the analytic, design, and modeling tools provided by Rational Software (including IBM Rational Rose, IBM Rational ClearCase, and IBM Rational XDE Developer), but they aren't required for its use.

RRD supports a top-down architect/designer approach to software development and lends itself to creating corporate standards, templates, procedures, and styles. Less experienced programmers can use precustomized elements to generate sophisticated code, particularly for the "plumbing" of an application such as database connectivity, application server operation, and distributed deployment. A number of other IDEs have a similar approach (such as IBM WebSphere Studio and Borland JBuilder), but few are as systematic as RRD.

Like But Not Like Other IDEs

Experienced Java developers will be struck by the number of elements in RRD that look and work familiarly yet fit into a distinctive framework. For example, RRD uses the project tree, a Windows Explorer-like hierarchical list of project elements. I don't think I've seen an IDE these days that doesn't use a project tree, but few, if any, have "Partition Models" (management of application partitions in n-tier systems) as one of the elements. Likewise, many IDEs use different modes, each with its own screen and tabbed pages, but only RRD's modes pertain to using "models" labeled: Application Architect, Class Architect, Site Architect, Page Architect, Theme Architect, Partition Architect, and Logic Architect.

The key steps in creating an application with RRD may sound unfamiliar: Make a class model, model the user interface (UI) and Web site, include page and logic modeling, then complete application integration, and finally move on to application maintenance. But these steps correspond in conventional terms to design and create databases, design and develop the UI (usually in conjunction with a Web site), design and create the Web pages and business rules (and transactions, if any), integrate (and test) all the components, and the usual end of the application life cycle — maintain the application. In short, "modeling" and the conventional steps in application development aren't very far apart.

However, most developers aren't accustomed to this model-based approach, and it isn't intuitive in the same sense as using a GUI screen to paint a form. The discipline of modeling — in particular understanding the relationships between design, coding, and the requirements of the project — isn't something picked up in an instant. Consequently, using RRD is a learned process and, for most shops, this means training — probably a lot of training.