Probably one of the most interesting tasks that can be given to an architect (system architect, program architect, lead architect, application architect - pick the title that resonates most in your environment) is the task of evaluating or determining the direction of an enterprise architecture.

It's a prestigious task - the opportunity to define the software basis for an entire corporation. It usually represents the Holy Grail to an architect. But it's also a task fraught with dangers - some real, some imagined.

From the perspective of a BEA WebLogic Developer's Journal reader, we can assume that the direction of the corporation from an IT standpoint is Java - in particular, Enterprise Java. So, at first blush, the task seems trivial: select a platform (WebLogic obviously), select a hardware vendor and a database vendor, and voilà - instant enterprise architecture.

Sweat and Tears
It's about this time that the cold sweat sets in. Because it's an extremely rare company that doesn't already have some previous investment in technology that it wants to milk for all it's worth. After all, if mainframes are so obsolete, why haven't they gone away? The answer is "ROI": the need to deliver Return On Investment.

So our intrepid architect now begins to realize that defining the enterprise architecture is a bit like defining an onion. No, not because it smells and lots of people don't like it...but because it has layers. And it's at this point that he realizes that the easy layers, the ones that everyone can see and relate to, have already been chosen for him.

As an example, we can more or less just assume that it's an Oracle database. Everyone needs a database and Oracle is the king, so it's easy to see the need to interface with Oracle. Databases aren't truly commodities, but it's been a long time since database selection worked as a selling point of an enterprise architecture. Like plumbing, almost the only time you give it a thought is when it isn't working. Still, when you choose a database, you also restrict some of your choices.

Likewise, the hardware choice is important because it determines your operating model and support structure. Often this is a murky subject, because the omnipresent and ever annoying mainframe lurks at the heart of most organizations, along with the idea of a separate transaction monitor, like IBM's CICS.

Which is fine you say; after all, Java will run on a mainframe. And yes, it will. But now we've peeled back another onion layer and started to understand about connecting the components to each other. And we start thinking - well, CICS is really about business logic, and don't I want that in my J2EE Server instead? Gotcha.

Deep Inside the Onion
So now we come to the more painful, hidden parts of the onion. Because up to now we've talked about the CIO level of architecture, namely the infrastructure and software platform. But once we get past that layer we realize that there are design patterns, methodologies, and best practices that need to be applied as well. The concept of local EJBs in the latest specification is a direct result of the realization that although you could have a client application (be it JSP/Servlets or Java applications) create direct connections to every EJB it needs to interact with, it's not an appropriate design pattern in terms of network efficiency and code execution, not to mention that it really negates the benefits of container-managed transactions.

In fact, the whole J2EE blueprint is an attempt to define best practices around a technology that's powerful, but easily misused. And that's just staying within the relatively safe confines of Java and J2EE. Now throw a monkey wrench into it with CICS, or add a CRM package that uses only JSP and Servlets, or a business rules engine that doesn't really understand EJBs and you can see where the architect begins to earn his pay: not by selecting the outside layers of the onion, but by ensuring that the inside layers aren't rotten.

Powerful Combination
Fortunately, with WebLogic, architects who are working in the Java space have pretty decent answers to these questions. CICS can be encapsulated in an EJB; WebLogic Integrate provides a business process engine that integrates well with EJB; and WebLogic Portal provides the plumbing around personalization. Add on the capability to treat WebLogic as a set of Web services, and that's a pretty powerful combination. Getting it to work together with the other systems and designing a flexible, scalable architecture, that's the real meat of the architecture. And that's what every architect lives for - peeling the onion.