I'm sure you've heard many of the cannibal jokes. One of my favorites is a news flash in a cannibal tribe announcing the invention of the "pressure cooker": "We have news of a device that cooks a man within minutes, and even lets out a whistle when it's done." Though technology brings to fruition concepts that were conceived of only a few decades ago, our expectations of technology far exceed the speed at which it makes solutions available. Often when I'm in the middle of architecting an n-tier application or framework using J2EE technologies, I find myself asking questions, such as: "What if I didn't have to write a line of code to achieve this," or "can I just cut-and-paste this into my next solution?"

My colleagues are often amused by my faith in the fine art of "cut-and-paste." However, when things are down to the wire, the speed at which existing code can be slightly modified through pure editing expertise is sometimes unmatchable. Of course, this can lead to redundant code, but that's one of the joys of three-month releases. When there's a deliverable next week, software engineering takes a backseat. That's the harsh reality of the software-development life cycle that many of us are subsumed in. The key is to go back and reengineer your solution. Of course, those days when you could just as easily engage external consultants to do so disappeared when the technology bubble burst.

Note that I am not advocating short-circuiting the software engineering cycle or circumventing the development process. Every time a shortcut is taken, it should be documented, and the appropriate design should be suggested ­ to be revisited at a later time. Fortunately, the latest Java IDEs offer several tools that alleviate the pain of this unconventional design cycle, such as refactoring support and reverse-engineering source code into modeling environments such as UML. The latest IDEs that I've worked with are IntelliJ's IDEA and Borland's JBuilder. Both offer these features, as do other competing products. Add unit and regression testing and source code control to the mix, and the proposed design cycle is almost achievable.

However, as software architects and developers, part of our job is to create the next level of abstraction. A software architect has substantial technology expertise as well as business-domain expertise. A J2EE architect utilizes his or her experience in applying Java's distributed technologies to a solution in the primary application domain. This involves creating not only reusable components and code, but also automating the process of software development for the next cycle.

I'd like to cite the example of one of my recent projects. Our mission was to build an application for the wireless domain. The choice of J2EE technologies was an obvious one, given our environment and our expertise. With the advent of EJB 2.0, the Enterprise JavaBeans­based implementation fit the bill (as opposed to a mix of JSP, servlet, JDBC, and EJB). The approach we took in our design was to automate the process of creating the middle-tier components (the EJBs), the hardest tier to build, test, and deploy. This included both the entity as well as the "accessor" session beans. We added utilities to generate components that leveraged the app server tools with the right level of business-domain components, so that we could replicate, enhance, and modify these components without rewriting too much code. The utilities also generate the database schemas and the constraints on the database. Although this effort cost us a precious couple of months in our release cycle, over a six-month cycle we were able to build an application that can now be applied across a variety of customers in our business domain.

Although there are no silver bullets, designing for reuse and automating component generation can take you a long way toward achieving your ultimate objective.