Having seen The Phantom Menace over the weekend, our admin, formerly of the real estate persuasion, dropped by to chat. The climactic scene, she said, told her she’s been working for us too long: (Warning: If you haven’t seen it yet, skip ahead because I’m about to reveal the ending.) After Anakin Skywalker blew up the Trade Federation’s spaceship in the nick o’ time, thereby inactivating the entire ‘droid army (a plot twist that caught yours truly completely off-guard) her only thought was “server’s down.”

“Hmmm,” I thought to myself. “I’m sure glad the Mandalorian CIO fell for the thin-client hype when designing the ‘droid army. And I just knew fat network architecture came from the dark side of the force!”

Over lunch the same day I talked to another colleague who’s a yachtsman (OK, he owns a boat). He told me about a guy who sells gas to everyone in his marina. The guy had to hire an assistant to pump the gas. Why? Seems his company installed a new computer system. His new system relies on a fat network architecture, with results as predictable as The Phantom Menace’s ending: Each transaction now takes several minutes to complete. Until he hired the assistant the line of boats grew long and their owners became increasingly impatient.

Want to bet that with a fatter client, response time would have been good enough to avoid the cost of that assistant?

Nearly everything you read about thin clients is bogus. If you want to keep things straight, keep a single fact in mind and you won’t go wrong: “clients” and “servers” are software processes, not hardware devices. Clients request services, servers provide them. The devices we call servers are really computers running operating systems designed to host server processes.

Remember that clients and servers are software and you won’t write monolithic applications, install them on web servers so they’re accessible through a browser and congratulate yourself on implementing a thin-client solution even though your business logic is inaccessible.

You also won’t fall for the “software on the desktop is bad; software on the server is good” claptrap that led to the hiring of the gas-pumping assistant and the fall of the ‘droid army. Read any article promoting this philosophy and you’ll find a common design priority: Minimizing Total Cost of Ownership (TCO).

As an IS manager you generally won’t design software, but you will establish priorities for those who do. Is your most important one minimizing cost, or is it maximizing end-user effectiveness? Remember, form follows function, so when your software architects design to minimize cost you’ll get a very different result than when they design to maximize end-user effectiveness.

Want to maximize end-user effectiveness? Isolate business logic and integration logic into modules that are separate from presentation logic and callable whether they’re installed on a local hard drive or on a network server. That way, software design doesn’t dictate run-time deployment.

Want to maximize end-user effectiveness? Since response time is probably the single most important part of “user-friendly”, install each module based on frequency of use rather than on IS convenience. Put the most frequently used modules on hard drives, moderately used modules on centrally managed LAN-attached servers, and infrequently used modules on centrally-located WAN-attached servers.

Want to maximize end-user effectiveness? Design solutions so that for critical applications desktops can continue to function (albeit in “degraded mode”) when the network or a server is down.

Keep in mind that with fat-network designs, when a server crashes everyone is down. If an application relies on three physical servers, each delivering 99% reliability, the application will only be up 97% of the time — about an hour’s worth of crashes each week — so designing for server unavailability is important. (In contrast, when a desktop crashes a single individual is down … and a three-finger salute will fix things.)

Remember: Clients should always be thin. Whether you deploy a fat desktop or a fat network is an entirely separate question.

Stupidity comes in two flavors.

Sometimes, we just don’t think. We forget anniversaries, miss our freeway exits, sleep past our bus-stop, call one of our kids by the dog’s name. Stupid.

It’s stupidity, but it’s OK, for two reasons. First, we’re all bozos on this particular bus. Second, we’re stupid because the smart thought never came near us to be chosen instead. We were sleeping with our eyes wide open.

Then there’s Microsoft Outlook. Why, oh why would you design a system that replicates all server data on my local hard drive, then uses expensive, slow, network bandwidth for every operation when the free, fast connection between my hard drive and the CPU is there for the asking? I could, of course, use the “Work Remote” option, only then Outlook can’t use the network link, only the modem connection. This is ActiveStupidity.

(Disclaimer: I’m picking on Outlook because I use it. For all I know, Notes and GroupWise are just as bad.)

Then there’s IS’s current love-affair with browser-based applications. I use one on a regular basis, through a 128Kbps WAN connection, and what would be a 1-minute job with a client/server GUI instead takes 10 minutes of mostly thumb-twiddling.

IS has fallen in love with fat network architectures. Fully buzzword-compliant software companies call browser-based user interfaces “thin-client” applications, but they aren’t, because a) browsers aren’t thin, and b) the thinness of the client doesn’t depend on where it executes, only on how well the business logic has been isolated from the presentation. I’d like everyone who misuses the term “thin client” to write this on the blackboard 50 times: “A ‘client’ is a software process that makes a request of another software process. A ‘server’ is a software process that receives a request from a client and satisfies it.”

Architectures that ignore the capabilities built into intelligent desktops in favor of servers at the wrong end of a WAN link may or may not be thin-client architectures. They are fat-network architectures every time, though, because they require faster (read “more expensive”) WAN connections and bigger (read “more expensive”) servers to achieve a user experience that’s a fraction as satisfying as the one you can achieve through a local GUI.

IS has fallen in love with fat network architectures because they’re easier to manage than n-tier client/server architectures. Never mind that an increasing fraction of the workforce is mobile, where bandwidth is limited to modem speeds and the laptop is tethered to a hotel telephone. Our Total Cost of Ownership has gone down! Break out the champagne.

A correspondent from a prominent software supplier noted for its advocacy of fat-network systems took me to task a while back for missing their elegant beauty. His company’s system, for example, downloads Java applications that supplement the browser’s limited functionality in tiny little 100KB chunks. “It runs over a 56Kbps modem!” he enthused.

Let’s see. Factoring in protocol overhead, a 56Kbps link delivers a little over 5.6KBps. That means each of those tiny little Java applications will download in only … 17 seconds. There’s a satisfying response time. Never mind the sub-second response time you’d get with software installed on the hard drive. To keep the delay under 2 seconds you need to connect at full T-1 speeds. Take a look at your WAN. How many 128Kbps links would you need to upgrade?

I don’t get it. Pundits keep writing about the ultimate in thin-clientness: Keeping all their private files on nice, public servers so they can access them anywhere through public terminals … along with every cyber-vandal and cracker on the Internet. That’s much better. Of course, they’d still have to haul their suitcases and briefcases around, but it would easily eliminate 10 percent of the total luggage weight.

Given a choice, I’d rather lug my laptop and rent clothes from the hotel. No more lost luggage, no more suitcases to drag through the airport … it would be a slice o’ heaven.

I could really get behind a “thin-luggage architecture.”