Technology – Page 199 – IS Survivor Publishing

How not to keep the Internet from collapsing (first appeared in InfoWorld)

If you blow enough smoke, you’ll convince a lot of people there’s a fire somewhere.

Last year, Bob Metcalfe and other pundits predicted the imminent collapse of the Internet. I, on the other hand, courageously predicted its non-collapse, and even more courageously endorsed the free-market economic model on which it is based.

The collapse contingent cites big outages last year, especially at Netcom and AOL, as evidence of the coming collapse. Their recommendation: throw a big party for the Internet’s inventors, thank them, shake their hands, and send them home so professionals can take over the job, replacing the current “anarchy” with modern central administration.

Here’s where I get lost. Netcom and AOL are private corporations operating centrally planned and administered networks. Both suffered big, noisy, noticeable outages. So to save the Internet from collapse, we want to centrally plan and administer it?

What am I missing? Most Americans think communism collapsed because big, centrally planned and managed economies don’t work. Most Americans are right. The Internet’s stability comes from its decentralized model. Rules are established centrally and kept simple – hence “Simple Network Management Protocol (SNMP) and “Simple Mail Transport Protocol” (SMTP) – while implementation of the rules is decentralized.

(One other problem with the proposed solution: there are no other professionals to call in. Only the Internet’s designers and implementers have experience in designing, building and running a successful, global network that links millions of independent computers. Who else are you gonna call?)

Despite all this enjoyable gloating, I give Dr. Metcalfe a lot of credit for sticking his neck way out, and for making a self-preventing prophesy. When disaster fails to strike, very few people give credit to those who sounded the alarm. I wonder how much of last year’s investment in Internet capacity resulted from the publicity attending Bob’s predictions.

Any lessons for you in all this? Ya, you betcha, as we say in Minnesota. The Internet’s successful use of centralized rule-making and decentralized implementation, far from being anarchic, gives you a wonderful model for organizational design.

Awhile back one of my readers sent me Sahakian’s Rules (Corporate Partnering Institute, Skokie, IL, 1995). It’s worth buying. One entry: “In ancient times, in order to manage large masses of people in the battlefield, Commanders used gongs, banners and horns. If a plan of battle was not simple enough to communicate with gongs, banners, or horns, it was a bad battle plan.”

Manage your organization like the Internet, or like a Commander on an ancient battlefield: with simple, easily communicated rules, not close, central supervision.

One other useful lesson: when you manage, ignore currently fashionable theories, especially those that demonize some group that Isn’t You. The idea that current Internet management doesn’t hack it anymore comes from one such notion that I call the BIG/GAS theory (for “Business Is Great/Government and Academics are Stupid”).

Yes, you can certainly find waste in government. Some comes from its sheer size, more comes from having lawyers (most of Congress) designing work processes, and much of the rest is unavoidable. (The military, for example, is staffed to conduct wars. When there’s no war, it’s over-staffed. Big deal.)

While government isn’t as good as it could be, the Internet’s history proves that BIG/GAS is just … vapor. In the 1960s visionaries in the academic and defense community created it. It’s been an international reality for decades.

In the 1980s the Graphic Communications Association (where, coincidentally, I worked for a few years) began creating the Standard Generalized Markup Language (SGML). Commercial publishers ignored it; the defense community embraced it as part of its Computer Aided Logistics System (CALS). Early in this decade, Tim Berners-Lee, working at CERN (the international particle physics laboratory) adapted SGML to invented the HyperText Markup Language (HTML).

And business finally caught on three years ago. BIG/GAS indeed.

Inhaling network computers (first appeared in InfoWorld)

Here’s a scary fact: Kofi Annan, the new Secretary General of the United Nations, went to the same college I did, although his stint at Macalester preceded mine by a dozen years. Maybe he needs help managing his technology. Do you think?

At Mac in the early seventies, the grass always looked greener under the other guy’s Gro-lux. It wasn’t, of course – it smoked just the same. (I, of course, didn’t inhale, already planning my future in politics, and Mr. Annan left Mac before weed became easy to come by there.)

Based on reader responses to my debate with Nick Petreley over the Network Computer (the RL/NP NC DB), it’s clear our industry isn’t immune from greener-grass disease, either. NCs sit across the fence. They don’t exist yet, so they possess magical properties that solve every problem ever ascribed to the PC.

Reality won’t be so thrilling, of course, because Java is slow and prototype NCs run like sludge. But don’t worry: Java chips, just-in-time compilers, or some other yet-to-be-invented innovation will take care of that. Or else Digital will take Nick’s advice and reposition its Alpha chip as an NC processor to bring Java up to PC performance levels.

But I’m tired of arguing, so instead I’m going to help all you NC advocates make the system succeed in your organization. Proper migration to any new architecture requires careful planning to minimize disruption. Here’s the program:

Step 1: Migrate to all Java applications: Every NC advocate has explained that NCs won’t replace all PCs – just some of them. Since electronic document sharing will continue to be important when you add NCs, you’ll need to use the same word processors and spreadsheets on both NCs and PCs. Right now that means converting to Corel Office across the board.

This is a low-risk move anyway, so jump right in. If you compare Corel’s price and licensing, you’ll see immediate economies of between 400 and 1000% even if you change your mind about installing NCs.

Go for it.

Step 2: Inventory all departmentally developed applications and write replacements in Java: Whether you know it or not, end-users have built a bunch of small systems using tools like Access and Paradox, or even plain old Excel with some macros. Power users build them, but lots of just-plain-ordinary users rely on them every day so you have to replace them with something that will run on NCs. This shouldn’t take more than a few staff-years of effort, and it will be worth it in the long run. Especially when you figure that since the NC doesn’t have anything equivalent to Access, departments will come to you again for these small applications instead of developing them on their own.

Step 3: Convert to SMTP/POP/IMAP e-mail: Well you’re not going to be able to run cc:Mail, MS Exchange or Groupwise on an NC, are you? You need to use an e-mail system you can access through a browser, and that means using the same e-mail technology used in the Internet – not a bad idea when you get right down to it.

Step 4: Beef up your LAN with a high-speed backbone, switching hubs throughout, and high-performance network management: You’re going to need the bandwidth, since you’re going to be downloading all of your applications through the LAN, and you’ll need the network management because any network outage will have a much bigger impact than before.

Step 5: Clear out most of your Netware servers and convert them to Web servers: You could use Netware’s Intranet products, but they’re not renowned for their great TCP/IP performance, and nobody has been promoting NCs that use Novell’s IPX protocol.

Now you’re ready to install NCs around the company. And it should be worth it, so long as real NCs have the same characteristics as the slideware we’ve been basing our plans on.