When a company beams aboard the enterprise, it’s truly going where it has never gone before. The point of the enterprise paradigm is to connect a company internally, to connect it to other companies, and, most important, to connect it to customers and other users of services in new and better ways. By definition, this will be uncharted territory. Both the IT systems that companies employ and their means of building them must be improved, using new methods and practices that must be evaluated and then mastered.

Disaster looms for the IT manager who fails to plan adequately for the cost of the paradigm shift. If you look at an enterprise effort from the top, you see the usual story: Set goals and objectives, interview users, write specs, develop programs, test systems. The programs do different things, of course, but to the casual eye, the tasks are familiar. Don’t you believe it; there’s a hidden layer of development lurking under the surface. Take a good look at it before beginning your design work and selecting your tools.

Putting a good face on it
Moving to an enterprise platform means tying your in-house databases and online transaction processing systems together, and that means standardizing your user interfaces. Often, if you’re implementing one of the major enterprise packages, this standardization comes in a can. But these days, the market will drive you further: You need to present a new face to the outside world.

Opening up IT services on the Web, whether for a restricted customer group or for the public at large, will require your dexterous implementation of browser-based applications. Content will drive this to a large degree, as will the particulars of access, with all the attendant security considerations. But you’re going to need tools for interface implementation, and those tools will need to be compatible with a general framework that functions well with your database environment.

You’ll need to consider the following:

  • XML—If you’re not there yet, read up. This is your key to powerful, flexible, and maintainable manipulation of content for presentation purposes.
  • XSL—Some people find it intimidating, but style-sheet processing will give you tremendous long-term productivity gains in maintaining a consistent Web presentation.
  • Java Server Pages—While there’s a great deal of processing that can be reasonably offloaded to the client’s browser, you still must place user convenience first. JSP is your server-side content manipulation interface of choice.

You’ve been framed
You’ve probably been hammering the point home for months, and senior management is very clear that the whole reason the company is going enterprise is to adopt a true IT service orientation, to improve business cycles, and reposition the customer as a process driver. You’re reengineering IT into a service-based framework.

Now realize that this service-based framework is much more than just a heady concept or slogan. You have to build the thing: It’s a modular functionality standard. What does this entail? Well, since rapid response to the marketplace is the whole point, you need an extended IT transactional framework that will allow a modular approach to the implementation of new processes or services. That is, you must have a framework that permits you to simply plug in new apps alongside existing ones, with which they must often interact (and interact correctly, sometimes in complex fashion right out of the gate). It must be availed of all the same infrastructural features and considerations and, if you’re smart, must be generalized to boot.

For this, you need a components-based interface architecture between data storage and presentation. And since you’re probably facing a broad range of applications (from OLTP to data warehousing, with lots of odd stuff in between), you’ll probably need to accommodate a number of “local” APIs that will permit your developers to maintain standardization and generalization as this component architecture comes together, app by app.

Give very careful consideration to the amount of time that you and your team will burn, clearly thinking through such a components-based world, establishing the standards, and taking into account the particulars of the systems that must be integrated. This undertaking will eat up huge portions of your resources if you underestimate it. And resolve now to select a development platform that will deliver as much standardization and generalization as possible.

Is it any wonder that I would recommend Java 2 Enterprise Edition at this point? Java is the battle-proven standard for well-integrated Internet application programming, and it offers a range of APIs that will give you the internal compatibility you’ll need. In addition to short-cutting your integration process and offering you out-of-the-box compatibility with your presentation tools, J2EE also offers your developers a proven application programming model (APM) that will guide them in building and integrating components with different application-level APIs.

Raising new barns
Odds are, your data is tucked away in an RDBMS or two. As you consider the design requirements of your enterprise apps, you must also consider whether a conventional relational database system is best for meeting your storage/access needs, or whether you should try something else. If you try to squeeze into the wrong one, you’re going to end up with a kludgy system and thousands of wasted hours.

Since the enterprise challenges put forth thus far mesh nicely with the Internet-friendly Java solutions, you have a viable alternative to RDBMS: Internet-friendly directory servers with the Lightweight Directory Access Protocol (LDAP). But it’s important to understand that it isn’t an either/or proposition. You can easily (and often prudently) mix and match RDBMS and directory server systems.

In deciding what kind of storage facility is best, think of your data storage needs not as black and white, but as falling into a fuzzy continuum. The less dynamic the data, the more suited it is to RDBMS. This usually means records that require general access—customer purchase records, etc. This kind of information is seldom required in a hurry. Random access storage is fine. So the RDBMS isn’t going to be tuned for the kind of access that more dynamic information (real-time searches—shipping status records, for instance) will require. For this, you need fast reads and faster searches, and a system that is easily tuned for that kind of operation is a directory server.

Again, Java comes to your rescue. For LDAP storage systems, you can use the Java Naming and Directory Interface (JNDI). For more conventional database systems, JavaBeans is for you.

Ready to beam up
As with any new system implementation, you’ll be rewarded in your enterprise effort with 10 hours saved for every hour spent planning carefully up-front. Realize from the outset that new thinking in storage issues, a “services” framework, and presentation requirements are going to cost you lots of research and design time. Equip yourself with tools that are designed with these issues in mind, and you’ll save yourself an ocean of time.