All Posts in Technology

|In: Industry Commentary|Last Updated:

The electronic mailbag got pretty full after my column on the Microsoft/Justice Department controversy. (See “The Justice Department’s action on Microsoft has everyone missing the point,” April 20, page 104.) Most letters were complimentary. A few pointed out that since Microsoft has a “noncoercive” monopoly it will eventually fail without government intervention. Their conclusion: Keep government out of it.

Well, OK. In fact, since muggers eventually die of old age, I guess we don’t need to prosecute them either.

Some readers thought I wanted to prevent Microsoft from integrating Internet Explorer into its future operating systems. Heck, it can build it into Hydra for all I care (just what you’d want, too: a Windows desktop accessing a server-based browser –- the ultimate “stupid client architecture”).

But no matter how much Microsoft sings, dances, and plays the tuba, Internet Explorer isn’t part of the Windows 95 or Windows NT 4.0 operating systems.

The biggest question on everyone’s mind, though, is whether Microsoft really has a monopoly in desktop operating systems. Since this hits you where you live, let’s take a close look. Do you have any real alternatives to Windows?

If you’re the CIO for a typical company, you’re establishing an architecture, not buying stand-alone PCs, so you probably have these requirements:

1. A quality word processor, electronic spreadsheet, end-user database, e-mail client, and Internet browser for general users. You’d prefer Microsoft Office since that’s the format used by most of your business partners.

2. A platform for commercial client/server business applications (accounting, payroll, inventory, or a whole enterprise resource planning system). You need a platform most vendors build for.

3. A platform for which you can develop and deploy in-house client/server business applications. Typical in-house applications have to last a decade or two, so future support is critical. And this OS has to match the OS that fits requirement No. 2 since you’ll need to run both in-house and commercial applications on the same desktops.

4. If the OS that satisfies requirements No. 2 and No. 3 isn’t the OS for general users, it has to support the same office suite or you can’t share files electronically. (No, “Save as .rtf” isn’t good enough.)

Quality engineering doesn’t make the list as a requirement.

An OS that satisfies all requirements can be the company standard. An OS that satisfies No. 1 and No. 4 can participate in a mixed architecture. Other OSes may run on some desktops, but only for specialty uses.

Windows passes all the tests. How about the alternatives: Unix, OS/2, and Macintosh?

Unix fails requirement No. 2, so you can only use it in a mixed architecture. And no Unix satisfies requirement No. 4. Scratch Unix.

OS/2? With SmartSuite OS/2 partially satisfies No. 1 and fully satisfies No. 4. It fails No. 2, though –- few manufacturers of business software create OS/2 clients anymore –- and as a result, No. 3 as well. You can use OS/2 except where you need to deploy client/server applications.

How about the Mac? With Microsoft Office it satisfies requirements No. 1 and No. 4 nicely.

The Mac, however, fails dismally on requirements No. 2 and No. 3. So although you can use Macs in a mixed environment, you can’t make them the standard, only a niche participant in your architecture.

Then there are the intangibles, like availability of suppliers, support, and programming talent. All of these make Windows more attractive than its competitors.

So here are your options: Use Macintoshes for general-purpose desktops and Windows for those running business applications, or use Windows for everything and save yourself the headaches of a mixed environment.

A judge and jury will have to decide if, for desktop operating systems, Windows fits the legal definition of monopoly.

Do you, as a typical CIO, have a realistic desktop operating system alternative today? The answer is pretty clear, even if you don’t like it.

Comments

|In: Organizational Effectiveness|Last Updated:

Some ideas pop up in every culture.

An old Islamic proverb advises you to “Trust in Allah, but tie your camel.” Former President Reagan translated the Russian version — “Trust but verify.”

And we chip-heads have extranets.

I gave my first speech about extranets to the Minnesota Telecommunications Association in 1993, not that I was smart enough to coin the term.

It was a simpleminded speech. The World Wide Web was just getting started, e-mail gateways were expensive and unreliable, and the office suite wars were still raging with no clear winner yet in sight. So I guessed wrong on many of the specifics. The key point was right, though. IT’s focus was typically internal — on WANs, which improved communications with ourselves, not on ways to improve communications with customers.

An extranet is a private network connection between two or more companies built around standard Internet technologies. I’ve recently moved from speechifying to setting one up, finding out first-hand that successful extranets have some tricky, trust-but-verify-related design issues. For example:

Security policy: Does yours describe the level of trust you assign to your customers’ employees? You can’t toss this problem over the transom to your security group either: Their job is to implement your security policy, not to create it.

Firewalls: You need one per company, of course, not a particularly sophisticated insight by itself. Each company needs to protect its network from its trusted partners. Don’t, by the way, economize by using the same firewall for your Internet and extranet connections. Each implements a different security policy. Internet users are total strangers. Presumably you trust extranet users more.

Authentication servers: If an extranet is a good idea for one customer it’s a good idea for lots of them. And once you’ve established an extranet connection to two customers, you’ve connected their networks to each other. They may even be competitors.

Authentication servers restrict the use of extranet connections to trusted individuals, protecting your customers from each other. A key point here: Your role is to encourage your customers to implement this technology. They each have to install and administer it. Otherwise you’ve taken ownership of their network security, along with the liability if something goes wrong.

In the Fun-You-Don’t-Need department, think about compatibility testing. Authentication servers require client software on every system that accesses the extranet. Different customers may choose different authentication servers.

Server ownership: In some cases this is a non-issue. What if you’re running a joint project, though? Like a lot of issues, this one’s easy to resolve if you remember it. One company or the other owns and administers the server and puts it inside their firewall.

Mobile users: This is the toughest design issue your network engineers face. When you’ve established a joint project team and a customer’s team comes to visit, you should be able to provide desks and network connections. They should be able to work without right-clicking on Network Neighborhood to reconfigure their IP settings.

Problem resolution: Don’t forget this one. Although every device on your extranet may be fully managed, the end-to-end connection is not. When something fails, nobody knows whose device is at fault. You’ll need reporting and escalation procedures. Probably, each company’s employees will call their own help desks. Instead of pointing fingers at each other, the help desks will work together to solve the problems.

And last but by no means least: Make sure everyone involved knows why you’re doing this. “Improving communications with our customers” sounds really great, but as Gertrude Stein said about Oakland, there’s no there there. If you think through the tangible benefits up front, everyone involved will know what they’re trying to accomplish.

Comments