In the mid 1990s, I worked with an application development environment (ADE) called Forte - essentially, PowerBuilder on steroids. It allowed for scalable, distributed applications to be developed, debugged, and deployed easily within a single environment. The technology was really cool. Sun Microsystems thought so too...and duly purchased the company, Forte Software, Inc., a few years ago. Anyway, Forte's marketing group wanted to express the ADE's power through its packaging - a tough message to relay to developers, who tend to be more interested in the actual installation CD than the box it comes in. However, the design on the cover of the Forté ADE box hit a home run, especially with those who had architected a complex, n-tiered system before. The cover had a large building on it. The building was constructed following an architect's blueprint, and assembled from components such as pre-built support beams, windows, and so on.

To me, the message was clear, and following in Forte's footsteps, whenever I talk about distributed architectures, I often use the analogy of a building as well. To help people understand the importance of architecture in a large system, I like to make the comparison between building a doghouse and building a skyscraper.

Alan Kay, one of the founders of the famed Xerox Palo Alto Research Center, once said, "Architecture dominates materials when addressing highly complex structures." In other words, materials should dominate when building a simple doghouse. "Should I use plywood or pressboard? Should I use a hammer or a nail gun?" There's no real need to draft a blueprint of a simple doghouse, since it would add little value when deciding what materials and tools to use for the job.

On the other hand, when you are designing large, complex buildings or enterprise systems, architecture dominates. Architecture provides a blueprint of the solution you're building. A contractor building a skyscraper without a blueprint might be left wondering if the plumbing pipes in the middle of the conference room could have been avoided whereas a blueprint of the building would've flagged the mistake immediately.

Similarly, software architecture isolates complexity into manageable components, allowing you to see problems with your design more easily. Architecture separates interface from implementation, to allow a skeleton structure to remain even when you are replacing the guts. Architecture also allows you to plan for portability and flexibility if change is necessary.

As Java became a contender for enterprise development, homegrown architectures arose around a disparate group of Java APIs like RMI, and servlets for handling HTTP requests. On their own, these APIs were used to solve problems like distributed communications; but when, where, and how to use them together was left up to you and your architectural guidelines.

Today, the Enterprise Java APIs have been bundled into a logical package called the Java 2 Enterprise Edition (J2EE) platform. The J2EE platform and the Sun Blueprints Design Guidelines for J2EE (J2EE blueprints) address difficult architectural problems such as these. With J2EE, Sun Microsystems - aided by contributions from BEA Systems and others - has laid a foundation for developing complex systems in Java.

I agree that architecture must dominate a complex system. However, I believe that the right materials and tools are also necessary to build a large building or system properly. Can a skyscraper builder be successful without a forklift or crane? How high can the forklift lift? To what heights can the crane reach?

The J2EE platform is merely a foundation upon which vendors provide tools necessary to build scalable solutions. BEA, an early adopter of J2EE, provides the most scalable enterprise development platform in the industry. This month in WLDJ, we'll investigate why WebLogic is the platform of choice when developing J2EE applications.