All Posts in Organizational Effectiveness

|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: Leadership|Last Updated:

If you missed the news, the population just hit 6 billion.

That’s a lot of people. If we were all to lie down end-to-end on the ground, we would go around the earth about 2,600 times. If someone put us all in a swimming pool, packed tightly together like sardines or flying in coach-class, the pool would have to measure more than a quarter of a mile on each side.

Then there’s the Y3K problem: We’ll just about outweigh the earth itself by the year 3000. It’s enough to make you believe there are limits to growth.

Amazingly, with all these people to choose from, many IS hiring managers can’t find enough qualified applicants to fill their open positions.

We can’t solve everything at once, so today we’re going to focus on just one small part of the problem: the help desk.

For many of those running IS, the help desk is an afterthought. It isn’t strategic, executives don’t interact with it very much (and when they do they get special treatment), and it generates no measurable return on investment.

Let’s recalibrate. The level of trust and respect between IS and the rest of the business is pretty low these days. (I base this on a large volume of anecdotal evidence, not formal surveys; your mileage may vary.) Your help desk is, or at least should be, the most frequent point of contact between your organization and the employees whose trust and respect you need every time you implement new technology.

The first step in making sure your help desk increases that trust and respect is staffing it with people who can actually solve problems instead of simply dispatching a trouble ticket to a technician.

Except … Bob, you idiot! Haven’t you heard there’s an IT labor crunch? If we do find people like this, we have more important places to use them.

News flash: You don’t need computer science majors on the help desk. Chances are, they wouldn’t be able to figure out that the end-user has a notebook resting on one of the cursor keys anyway. Here’s who you do need on your help desk:

  • High school seniors: Sure, you’ll only get them for a few hours a day during the school year (more during the summer, of course). But who better to diagnose PC problems than someone who assembled a high-end gaming system from spare parts? You can pay a lot more than the local Taco Bell and still save a ton compared to those computer scientists you can’t find anyway.
  • College students: Yes, you’ll have to work around class schedules, and you’ll have to pay more than you would pay a high school student. Here’s the upside: You get highly qualified help desk analysts, still at low cost, and they’re all potential recruits when they graduate. After a year, you’ll know who you’re going to want to hire – offer them scholarships in exchange for two years as full-time employees when they leave college.
  • Internal PC mentors: These are the people employees call when they need help because they’ll solve the problem before your help desk would have finished writing up the trouble ticket. They’re already employees, they’ve already proven they can do the job, and many of them would love an opportunity to move into IS.
  • IS analysts: Rotate your analysts through stints on the help desk. Here’s what they’ll gain: humility (as they find out just how much they don’t know how to fix and how knowledgeable and sophisticated those dumb end-users really are); listening skills (because to fix problems they have to hear beyond the symptom to what’s really going on); a better understanding of how work gets done (they’ll see it first-hand); and, most important of all … they’ll learn what the rest of the company thinks of IS.

Staffing shortage? When it comes to the help desk, at least, we don’t suffer from a staffing shortage. All we suffer from is a lack of imagination.

Comments