All Posts in Technology

|In: Industry Commentary|Last Updated:

Microsoft’s posturing over AOL’s “obligation” to open up its proprietary instant messaging protocol was pretty funny; Micron Electronics’ plan to buy Micron Internet Services from their mutual parent Micron Technology is just plain bizarre. But Oracle’s Larry Ellison, topping the rest of the industry, wins in the definitions category by describing his company’s planned $150 (plus monitor) diskless Linux desktop system as a “network computer”.

This is a system that has 64MB of RAM and runs a Unix variant and applications that are installed locally from a CD-ROM. That makes it a network computer? So, I guess, is the iMac. It’s OK. Ellison coined the term “network computer.” He can define it as he pleases.

Speaking of newly coined buzzwords, my recent columns on fat network architectures generated a lot of e-mail and discussion in InfoWorld.com’s forums.

Many respondents disagreed with my proposition that “thin client” has lost all meaning. Several explained what the term “really” means. Regrettably, no two proposed the same definition …

Other exchanges centered on my conclusion that the one thing thin client architectures all share is their need for a fatter network (hence the name). Either missing my inclusion of servers as part of the network or disagreeing with it, they pointed to products such as Citrix and Virtual Network Computing (VNC) that make efficient use of bandwidth. Since fat network is my term, though, I get to define it, and servers are in.

VNC’s advocates in particular were emphatic about the wonders of their thin-client solution, and challenged me to “prove” my assertion that thinner clients require fatter networks. (Answer: See my definition, above.) If the number of capitalized sentences and exclamation points in its proponents’ postings is a gauge, VNC is worth exploring. The number of capitalized sentences and exclamation points also demonstrates the need for a more businesslike approach to product advocacy if the open source movement is to succeed.

In the end, when the flames had died and the smoke finally cleared, only a few points seemed certain regarding thin-client/fat-network computing:

1. Misuse of the term “thin client” has rendered it worthless. It now means “non-Windows desktops.”

2. The only benefits common to all fat network computing solutions are that they’re easier to deploy, stabilize and administer (please, not “administrate”) than applications installed on Windows desktops. Note to all who wrote: They aren’t more stable, only easier to make stable.

3. Browser-based computing benefits end-users – it allows IS to deploy applications that otherwise would be impractical to create at all.

4. The lonely defenders of HTML-only interfaces acknowledged their limitations, instead asserting that end-users need nothing more. Anyone who has filled out an on-screen purchase order knows better, though – HTML lacks basic facilities, like scrolling regions. To make browser-based applications competitive with modern GUIs you need combinations of JavaScript, Java applets and servlets, ASP, Perl … Techniques for maintaining applications built on all this stuff don’t exist.

5. NCs let you build rich user interfaces at the cost of locking down the desktop – sometimes appropriate, sometimes not – but at the cost of incompatible file formats for office applications. Lotus’ latest version of eSuite may change that, though, opening the door for a mixed PC/NC architecture.

Finally, at least within my unscientific sample, advocacy of thin clients and disdain for end-users correlate strongly. In the “real world,” I’m told, the only software end-users install is games and screen savers; IS knows what end-users need to succeed better than the end-users themselves; and what matters is what’s good for the company, not what helps individual employees do their jobs. Then in the next sentence or posting, I hear that IS lacks the resources to take care of every need in the company.

Put it all together and it comes down to the same, tired formula: We won’t do it for you and we won’t let you do it for yourself because we can’t trust you with the tools.

In IS, I guess, we need to update the old proverb thusly: “Give a man a fish and he eats for a day. Teach him to fish and he’ll wreck everything.”

Comments

|In: Industry Commentary|Last Updated:

Draw a circle.

Surround it with several more circles. Connect the new circles to the one in the center with lines.

This is your systems architecture. Before you read on, label each of the circles. I’ll wait.

OK, done? You almost certainly chose one of the following two labeling schemes: You either tagged the central circle with some synonym for mainframe, host, or server and the outside circles as terminals, PCs, or network computers; or you called the central circle a personal computer and the outside circles mainframe, server, minicomputer, World Wide Web, and other resources you can access through your PC.

If you chose the mainframe-centric labels, chances are you like the fat-network architectures now fashionable under the misleading “thin client” moniker. If, like me, you put the end-user in the middle of modern computing architectures, using a PC to draw on whatever resources are currently needed, you probably worry about the whole fat-network approach to systems design.

Fat-network systems come in two basic flavors: Windows terminals and “Webware” interfaces. What’s interesting about these two flavors is that they have exactly nothing in common except that they have both have been misrepresented as thin clients.

The Windows terminal approach, whether sold by Citrix, Microsoft, or any of the dozen or so remote-control vendors, is remarkable primarily because of how unremarkable it is. It ignores the application architecture entirely, instead providing an alternative for deploying the same old stuff. The term “architecture” really shouldn’t be applied to a Windows terminal solution at all, since all it does is extend the keyboard and screen across a network. It does, however, put the host firmly in the middle, since with Windows terminals IS tightly controls the resources available to end-users.

Webware is more intriguing. When you design applications around Webware, you have at your disposal browsers, JavaScript, downloaded Java applets and applications, Java servlets and server-based applications, active server pages, Notes/Domino applications, Perl scripts, and enough other choices to delay any development project for a year while you sort them all out.

A Webware architecture means some code gets downloaded for desktop execution while other code executes on the server. The only option not available to you when designing Webware is storing software (other than a “thin” 50MB or so browser) on local hard drives. In other words, you never use the fastest and cheapest storage you have. That makes sense … if you have decided to put the host in the middle.

Take a moment to go beyond cost of ownership to deal with the more interesting benefit of ownership, and you’ll discover that GUI applications installed on the desktop and Webware-based applications aren’t mutually exclusive alternatives. You’ll want to use n-tier, thin-client (in the true, skinny presentation layer sense), probably object-based architectures to build both.

As a general rule you’ll use desktop GUIs for high-use applications targeted to a known desktop platform … for example, whenever you’re building or selecting software to be used by employees as part of their core job functions.

When you do, follow the rules for easy, stable installations: Don’t touch the registry, don’t put anything in the Windows folder or any of its subfolders, test builds for memory leaks, and deploy the full application in a scale-model test environment before implementing it in production. Design every module for portability and manageability, too.

When you don’t know what end-users will run on their desktops, or when you need to deploy an application for occasional use, go for Webware. Here, the increased functionality of a desktop-installed GUI no longer outweighs the benefit of easier deployment.

When you’re building for Web access, you have no control over bandwidth, so force developers to test applications on lowest-common-denominator (another misused term; they’re actually greatest-common-factor) systems. And … remember that testing and manageability thing? Building on Webware doesn’t eliminate the need for any of that.

When you’re building (or buying) for deployment on your intranet, don’t forget: Fatten up that network.

Putting the end-user in the middle doesn’t mean you want the data center to seem remote.

Comments