InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

January 11, 1999

Enterprise RAD Tools: Can They Do The Job?

Illustration by Matt Foster

continued...page 2 of 2

The developers say they chose Java because the users had identified a particular Java interface they liked during the requirements phase of the project. By making it a pure Java application, the developers could deliver the exact interface the users preferred and ensure that the application would work with all browsers, says Sadler.

The combination of Java and components from the Motorola library, and not any particular ERAD tool, helped speed development. The application took Sadler and another developer three months to build.

ERAD Need Precluded?
Java and component architectures may preclude the need for IT shops to adopt ERAD tools. Ernst & Young's systems development and technology group in Sacramento, Calif., turned to iterative Java development to quickly knock out enterprise applications. "The beauty of Java is that we can build a library of components and objects that we can reuse," explains Colette Coad, Ernst & Young's Java service-line leader.

Coad's team relied heavily on objects, frameworks, patterns, and design models from that library when it built a demanding forecasting application for Eli Lilly and Co., the Indianapolis pharmaceuticals company. The client expected the application would take nine months to build and even more time to deploy across 26 sites worldwide.

Using a fast, iterative, object-oriented approach and building the application in Java from existing objects as much as possible, the Ernst & Young team finished the application in nine weeks--about one-third the expected time. "And, we were able to deploy it in 26 locations at once just by flipping a switch," Coad adds. An added bonus: The application deployed with zero defects, which Coad attributes to the reuse of proven Java objects and effective testing during the building process.

Many organizations, however, are not yet ready for n-tier, distributed, Web-based systems or Java. For them, ERAD means building enhanced, large-scale versions of their older systems. "We looked at Java, but in 1996 it didn't have the functionality or the speed," says Steve Medina, director of application development at Carlson Hospitality Worldwide in Minneapolis.

Instead, Carlson opted for Forté Conductor as its enterprise RAD tool when it redeveloped its call-center reservation system for 500 hotels. The application was originally built using a proprietary programming language and Informix's C-ISAM database. "We had reached the limit of C-ISAM," says Medina. "It was never designed for 1 million records." But rather than port the application to a new database, the organization decided on a major overhaul.

The team replaced the C-ISAM database with Oracle and started building the application in Forté Conductor, an object-oriented fourth-generation language. Because of the flexibility of objects, the developers were able to encapsulate and interface with pieces of the legacy code. This allowed the company to keep portions of both the new and old systems functioning during a gradual, multiyear development effort.

Staying Updated
The new Carlson application is a two-tier, fat-client, enterprise app. To eliminate the problem of client-side deployment, the company built an electronic software deployment capability using Install Shield from InstallShield Software Corp. "We made sure we can maintain and enhance the application at each hotel," says Medina. Following a strategy of deploying early and often, Carlson deploys software enhancements and fixes electronically as often as two times a week to ensure that every hotel has the latest version.

Increasingly, the focus of enterprise developers is on middleware, not ERAD--at least not ERAD in the form of an integrated development environment (IDE). "Object request brokers are playing a much bigger role than in the past," notes Dave Kelly, VP of the Hurwitz Group, a software consulting firm. ORBs are just one of many forms of middleware being embraced by enterprise application developers.

For example, D.E. Shaw & Co., a New York investment bank, turned to middleware, not an IDE, when it needed to build a trading system infrastructure. The key issue wasn't speed of development but application scalability. Shaw intended the trading system infrastructure to support its ticker service and data feeds. The n-tier applications were complicated by a set of very demanding services crowding the middle tiers. These included an object service, persistence service, and business logic services.

Scalability loomed as the most difficult challenge. "We needed high performance and fault tolerance," says Gaurav Suri, VP of trading system infrastructure. The application had to handle upwards of 5,000 messages per second. For this, the development team turned to Talerian Corp.'s SmartSockets 5.0, a publish-and-subscribe middleware solution. The middleware tool freed developers from having to design and code the low-level interprocess communication, which makes up the bulk of this kind of application.

As much as developers need them, ERAD tools "present a catch-22 for developers," suggests Manu Matthews, director of consulting services at Primix Solutions Inc., a custom development shop in Watertown, Mass. Developers need advanced, often proprietary tools to meet user demands for speed, functionality, and scalability. Yet, the users balk at the latest technology for fear of support and maintenance problems down the road.

And to complicate matters even more, the demand for fast deliverables precludes a lengthy tool evaluation process, Matthews says. As a result, developers at Primix often find themselves trying to build enterprise applications with whatever the client has at hand, such as Visual Basic, or working directly in a low-level language, such as C, C++, or Java while ignoring higher-level tools altogether.

Ultimately, the need to tame the complexity of enterprise development will force a resolution of the catch-22 and drive the adoption of ERAD tools. What a comprehensive ERAD solution will look like by then isn't exactly clear, but it will likely combine a new generation of visual ERAD IDEs, a variety of integrated middleware tools, application modeling and design capabilities, and deployment tools.