Sports cars are typically measured by how fast they go from zero to sixty. But is that really the best measurement? Would a Honda Accord with a 500 hp V8 be a better sports car than a Porsche 911 Turbo? Obviously not. It takes a well-rounded vehicle to achieve this status - handling, braking, acceleration, reliability, etc. The same is true with development tools. Speed isn't everything. Agility is equally important. You need a well-rounded tool to create the best application.

Take portal development for example. Gene Phifer of Gartner has defined what he calls the "90/10-10/90 rule" for portal development. This rule states that in the initial phases of portal development, simple departmental portals, for example, 90% of the application's needs are met by out-of-the-box products - a very quick zero to sixty. But, as the applications evolve, they will leverage only 10% of this capability and will require 90% to be built as custom applications - requiring speed and agility.

Building J2EE-based applications, such as portals or custom portlets, is a difficult and iterative task. Rarely is an application built once and then never modified or updated. The average IT department spends 70%-80% of their time maintaining existing applications. There are lots of tools that can help you build applications quickly, from the out-of-the-box products with limited customization to code generators that make it easier to build and rebuild an application. But like the Accord with a V8 shoved under its hood, they only address part of the problem. You need to automate not only the development of these applications, but also their maintenance.

A portal can be an extremely powerful tool, provided it's presenting information that's relevant. Portals have an inherent need to change and adapt. One-size-fits-all portals give everybody some information, but nobody gets exactly the information they need. Portals need to change as the business evolves, and adapt to their surroundings.

If you're like most companies, you've moved beyond the simple departmental portal and are trying to provide an integrated view of your enterprise. This integrated view will be made up of a collection of custom portlets that need to adapt to their environment. No longer will you be able to create an application with a specific end user in mind. You've got to build applications that can serve all constituencies, and do it dynamically. How do you manage that kind of variability? It's relatively easy if you have 10 customers or partners. But what if there are 100 or 1,000 or even 100,000 that you need to support? How do you handle that level of customization?

You will need to make agility an element of the DNA of your portals - building them for change, not just for speed. You will achieve this by creating custom portlets, the pieces that will make up all of your portals, that can adapt dynamically and can be changed without the need for reprogramming through a centralized IT group. Using traditional out-of-the-box portlets, you would be required to push all changes through IT. With the need for customization increasing rapidly, this could create a serious traffic jam for your IT department. However, if you push out the customization of these portals and portlets to discrete business units, partners, or even the business users themselves, you can free your team of the costly burden of rewriting applications every time the business changes or you need a new iteration.

The complexities of J2EE development shouldn't outweigh the benefits of building great applications. But to date they have certainly stalled that effort. With the emergence of new tools that bring ease of development and maintenance to J2EE applications, your IT team will evolve from programmers who react to business change to application designers that anticipate change and put themselves, and your company, in the driver's seat.