All Posts in Technology

|In: Organizational Effectiveness|Last Updated:

The best note-taker of all time worked in a department I managed several years ago. I was reading his notes from a staff meeting when, on page two, in the middle of a sentence on some procedure change or other we’d agreed to, I read the following: “(If you’ve read this far, you’ll find a dollar bill under your telephone.)” after which his notes returned to the subject at hand.

Sure enough, I found the dollar. When I returned it, laughing, I asked how much the experiment cost him. Of the ten dollars he invested, he lost two bucks, of which I returned one. It’s a good thing to try. I recommend it.

Same guy, different meeting. The notes: a picture of a horse, on its back. Ten people with whips stand around in different poses. Some flog the horse, some flog other team members, one or two stand back as noncombatants.

Accurate notes.

I’ve participated in dead-horse-floggings before, so why should I stop now? Between the Forum on InfoWorld Electric and e-mail, the reaction to my “End-User Computing Manifesto” was hot enough to melt lead, so it’s time to flog further.

Several end-users, mostly Macintosh users, I’m afraid, became incensed at the “No Prima Donnas” entry. A prima donna, in this context, is someone who insists on using a tool that competes with the standard. If I insist on using WordPerfect when my company has standardized on MS Word, I’d be a prima donna.

Some suggestions were topologically and anatomically impossible. Most, though, seemed concerned over how IS comes up with its list of standards, assuming they’d exclude end-users. For the record: I can’t imagine circumstances that would justify selecting end-user software without end-user involvement. I also can’t imagine a selection process without a support analyst and someone from the networking group (to assess compatibility with and impact on the company network).

A few perceptive readers pointed out that “support” is pretty broad, and that several levels of support should be defined. Here’s a scheme I’ve used that’s worked well.

Level 5: Fully supported software. IS installs it, tests it for compatibility with all supported desktop environments, upgrades it when new releases become available, and provides both classroom training and one-on-one assistance. The IS software budget pays for it, too.

Level 4: Acceptable alternative software. Software that fully supports the native file formats of Level 5 software generally falls into this category. IS buys this software, installs it on the central file servers, and upgrades it when new releases become available. It doesn’t, however, provide classroom training or one-on-one support beyond the point this software diverges in use from the Level 5 standard.

Level 3: Departmental software. Any department may choose to buy and support whatever software seems important to its organizational success. IS will participate in the selection process to make sure this software is compatible with, and not destructive of, the overall network environment, and will provide a network directory for it if needed. The department takes responsibility for installation and management of the software though – IS has no operational involvement.

Level 2: Software acceptable for individual use. End-users can buy and install whatever they want on their local hard drives. They must be able to produce the original installation diskettes at any time (to demonstrate the legality of the software) and must be fully self-supporting in its use. If Level 2 software somehow makes a computer unstable, IS may choose to help, or it may offer to restore the desktop to a standard configuration to get it working.

Level 1: Software that’s not acceptable in the organization. Different companies have different qualifications here – some allow no shareware; few allow games.

Limiting end-users to company standards makes IS a gatekeeper, not an enabler. IS can’t, though, support everything anyone decides to buy. Multiple support levels let both groups succeed.

Comments

|In: Industry Commentary|Last Updated:

In what I laughingly call my spare time I teach a graduate course in computer communications at St. Thomas University. Since I’ve been trying to make sense of Virtual Local Area Networks (VLANs), the class got to write a term paper on the subject. I asked everyone to:

1. Provide a clear and coherent definition of the term VLAN.

2. Describe the situations VLANs have been designed to address, contrasting VLANs with the alternatives.

3. Analyze the claimed benefits of VLANs.

So … A VLAN is an administratively-defined rather than physically-defined LAN subnet. With VLANs you can put everyone in a workgroup on the same virtual segment regardless of their physical location. This is supposed to reduce administrative overhead.
It’s also supposed to reduce network traffic. How? Workgroup members communicate with each other more than with anyone else; VLANs keep workgroup traffic within one virtual segment. Also, instead of broadcast traffic propogating throughout the LAN, it gets restricted to “broadcast domains” that correspond to the same virtual segments. (If you’re not a network weenie: while most network packets go between specific nodes on a network, some have a destination address of “everyone” – the sender “broadcasts” them.)

There’s more, but when you’re in IS management you’re not supposed to understand technology in great depth. You’re supposed to understand its nature, purpose, and fit with your organization’s business needs.

You’re also supposed to have a high-quality BS Detector set for maximum scan, since our industry has the highest BS/Customer ratio of any profession. (BS, if you’re not familiar with the term, is short for “BuShwah”.)

I’ve graded 34 graduate papers. I’m concerned VLANs are mostly bushwah, because the problems they’re designed to solve may not be important problems in the first place.

Let’s take assigning workstations to logical workgroups. Most organizations still co-locate workgroups, so a VLAN virtual segment and the network’s physical segmentation would largely coincide. No big VLAN benefit there.

More important, most traffic goes from workstation to server and back, not from workstation to workstation. With everything attached to switching hubs (and VLANs require the use of switching hubs) workstations should see only their own packets even without VLANs, except for those pesky broadcast packets.

How much LAN traffic comes from broadcasts? I can say with complete confidence I have absolutely no idea. I do know this: a lot of broadcast traffic comes from older protocols like Novell’s SAP and RIP (System Advertisement Protocol and Router Information Protocol). Novell, though, has replaced SAP and RIP with NLSP (Netware Link Services Protocol) which dramatically reduces broadcast traffic – a good idea, and one that further reduces the value of VLANs.

How about the reduced network administration from moves, adds and changes? I’m completely baffled here. Network bridges and switches automatically learn the location of every station’s address on the network. Move a station and they learn the new location without intervention.

With VLANs, you get to assign each workstation to a virtual segment manually. Sounds like more work, not less, especially since you already have to define workgroups in your network directory service.

Lots of very smart people believe in the value of VLANs, though, and that makes me wonder what I’m missing. So I’m going to do what any good manager should do: ask an expert to do the hard work, after which I plan to take the credit.

Nick Petreley (you’ll see his smiling face a few pages from here) knows everything there is to know about technology. He and Charlotte Ziems, InfoWorld’s Test Center Director, want to do solutions-based testing anyway. I think VLANs would be a great solution to test.

Comments