Although we ran into late shipments and downtime courtesy of electricians ripping up the place--not to mention running out of caffeine more times than we can count--nothing frustrated us more than dealing with the applications necessary to run this little business we created. In fact, after listening to us vent about some database issues, contributing editor Don MacVittie's only comment was: "Welcome to the real world."

One of the most common causes of application problems is that people who write software make assumptions. And while some of those assumptions are good, others are just downright asinine. Take Microsoft DNS, for example. If you aren't networked when you install it, it will decide you want to be a root server. That's an example of an assumption that ought to be a configuration option. When you finally do network that machine, guess what? You can't do anything but resolve addresses in the configured zones. Our directory server (ADS) was the first machine we installed, and we didn't have it networked because we didn't have our switches yet. When we finally hooked it to a switch and set up routing to give the machines Internet access, you can imagine our consternation. And to add insult to injury, the cure wasn't pleasant: We deleted the "." zone, and every last pointer record in the reverse-lookup zone was deleted along with it. As for Microsoft DNS, well, address resolution stopped working entirely.

FYI Having integration anxiety? The Interoperability Clearinghouse seeks to "promote mechanisms for assuring the successful implementation of enterprise technology solutions." Members include Boeing, Microsoft and a number of government agencies, including the CIA, DARPA and NIST. See a complete list at www.ichnet.org/members.php.

And it's certainly not just Microsoft. IBM made some assumptions during the configuration of WebSphere Application Server that drove us batty. You can configure WebSphere to use IBM's HTTP Server (based on Apache) or Apache. In the last stages of the installation a dialog box pops up and asks for the location of the Web-server configuration file. Sweet. We set up a quick Samba share on the Web server machine and selected the file. IBM takes care of adding the necessary configuration to the file. Cool, right?

Wrong. We installed WebSphere on a Windows 2000 machine, so the installation assumed (there's that word again) that Apache was also installed on a Windows OS. Not in our lab it isn't. The changes had to be taken out and hand configuration ensued. No help is better than bad help.

WebSphere is also picky about the types of databases with which it will communicate. DB2? Of course. Sybase? Yes. Oracle? Yup. Informix? Naturally. SQL Server? No way. We had to tweak WebSphere's configuration, the most important of which was upgrading the JDBC drivers from version 1.0 to 2.0.

After the pain, however, comes the payoff: The hardware looks good, the blinking lights are all the right colors, and the applications are coming along nicely. But we're not finished. As we continue to review business applications we'll be testing them against this environment, and some will get to stay and become part of our little family. Unlike out other Real-World Labs®, where we often wipe all our machines and start with a clean slate, we won't be interrupting our business application lab by starting over from scratch. You don't have that option and, in this lab, neither do we.

Welcome to the real world of NWC Inc.