I think we have this Bill Gates thing all wrong.

Lots of IS managers responded to my column on the return of the mainframe mentality, concerned about the damage renegade end-users can cause. Most of these letters recommended processes that prevent end-users from making mistakes.

That’s when it hit me: Bill Gates is the one guy trying to maintain an out-of-control desktop.

Look at Microsoft’s tactics and contrast them with its competitors:

  • Microsoft invented TAPI (Telephony Application Program Interface) which links telephones and computers at the desktop. Novell and AT&T invented TSAPI (Telephony Services Application Program Interface) which provides similar services through a server/PBX connection. IS can control and manage TSAPI. End-users can use TAPI without IS ever knowing about it.
  • Microsoft is putting together “Peer Web Services” which will let everyone publish HTML documents on Intranet servers. This empowers end-users while making them harder to control. Meanwhile, Microsoft’s competitors are focusing on Java, which gives IS new ways to develop and control applications. Significant fact: making HTML the standard enterprise document format breaks Microsoft’s de facto monopoly in word processors.
  • Microsoft builds personal computer operating systems that run on autonomous desktops. Many of its competitors (Oracle, IBM, Sun) have embraced the notion of a network computer – one that only has the functionality IS provides through the network.
  • Microsoft focuses on ease of installation and use – for all the griping, Windows/95 installs with remarkably little pain in the vast majority of cases, and the real attraction of NT server over Unix, Netware, and even OS/2 is how easy it is to set up and administer.
  • You don’t hear Microsoft extolling the virtues of “thin clients” which, after all, waste the processing power at the desktop while requiring bigger servers for IS to run.

Microsoft’s competitors? They all develop for and sell to IS.

Novell used to market (okay, what substituted for marketing for the kids in Sodium Valley) to renegade department managers tired of waiting for central IS, and Novell became the dominant player in the LAN marketplace. Then Novell started to become legitimate, using “Enterprise” as an adjective and selling to central IS instead of its original customer base. Novell now focuses on technologies that increase IS’s ability to manage the enterprise. In the bargain, it has failed to gain significant market share for any product, no matter how excellent, that provides end-users with personal power and productivity.

Sun, IBM, Oracle, Digital? They’ve never heard of end-users, and probably wish they’d go away. End-user activities don’t sell big iron, or even medium-size iron. They don’t sell database servers (you have to deal with IS to get at those).

Yes, the Macintosh is the original end-user machine, and Apple had similar ideas. Unfortunately, years of inept management at Apple caused the product line to stagnate, boring the daylights out of everyone who watches this industry. We all may be willing to wait 15 minutes for a Web page to download, but we won’t tolerate boredom.

End users want to work without IS looking over their shoulders. They want to fiddle around, gradually creating exactly what they want, emerging only when the finished product is ready for inspection, whether it’s a document, a spreadsheet, or a small database application. That’s why personal computers became popular in the first place, and why the big players uniformly missed the boat.

Yes, Bill Gates is a fierce competitor, and in fact is one of just a few in the industry who knows what game they’re playing. Gates, along with Scott McNealy of Sun, Larry Ellison of Oracle, and maybe one or two others, is playing winner-takes-all poker. The rest are busy increasing shareholder value, maximizing profits, and doing all the other stuff that gains short-term success at the expense of world domination.

Only I wonder … does Chairman Bill really want to rule the world, or is he playing a deeper game?

Technology … all successful technology … follows a predictable life cycle: Hype, Disillusionment, Application.

Some academic type or other hatches a nifty idea in a university lab and industry pundits explain why it will never fly (it’s impossible in the first place, it won’t scale up, it’s technology-driven instead of a response to customer demand … you know this predictable litany of nay-saying foolishness).

When it flies anyway, the Wall Street Journal runs an article proclaiming it to be real, and everyone starts hyping the daylights out of it, creating hysterical promises of its wonders.

Driven by piles of money, early adopters glom onto the technology and figure out how to make it work outside the lab. For some reason, people express surprise at how complicated it turns out to be, and become disillusioned that it didn’t get us to Mars, cure cancer, and repel sharks without costing more than a dime.

As this disillusionment reaches a crescendo of I-told-you-so-ism, led by headline-grabbing cost-accountants brandishing wildly inflated cost estimates, unimpressed professionals figure out what the technology is really good for, and make solid returns on their investments in it.

Client/server technology has just entered the disillusionment phase. I have proof – a growing collection of recent articles proclaiming the imminent demise of client/server computing. Performance problems and cost overruns are killing it, we’re told, but Intranets will save it.

Perfect: a technology hitting its stride in the Hype phase will rescue its predecessor from Disillusionment.

What a bunch of malarkey.

It’s absolutely true that far too many client/server development projects run way over the originally estimated cost. It’s also true that most client/server implementations experience performance problems.

Big deal. Here’s a fact: most information systems projects, regardless of platform, experience cost overruns, implementation delays, and initial performance problems, if they ever get finished at all. Neither the problem nor the solution has anything to do with technology – look, instead, to ancient and poorly conceived development methodologies, poor project management, and a bad job of managing expectations.

I’m hearing industry “experts” talk about costs three to six times greater than for comparable mainframe systems – and these are people who ought to know better.

I have yet to see a mainframe system that’s remotely comparable to a client/server system. If anyone bothered to create a client/server application that used character-mode screens to provide the user-hostile interface typical of mainframe systems, the cost comparison would look very different. The cost of GUI design and coding is being assigned to the client/server architecture, leading to a lot of unnecessary confusion. But of course, a headline reading, “GUIs Cost More than 3278 Screens!” wouldn’t grab much attention.

And this points us to the key issue: the client/server environment isn’t just a different kind of mainframe. It’s a different kind of environment with different strengths, weaknesses, and characteristics. Client/server projects get into the worst trouble when developers ignore those differences.

Client/server systems do interactive processing very well. Big batch runs tend to create challenges. Mainframes are optimized for batch, with industrial-strength scheduling systems and screamingly fast block I/O processing. They’re not as good, though, at on-line interactive work.

You can interface client/server systems to anything at all with relative ease. You interface with mainframe systems either by emulating a terminal and “screen-scraping,” by buying hyper-expensive middleware gateways (I wonder how much of the typical client/server cost over-run comes from the need for interfaces with legacy systems?), or by the arcane issues of setting up and interfacing with LU2 process-to-process communication.

And of course, the development tools available for client/server development make those available for mainframes look sickly. Here’s a question for you to ponder: Delphi, Powerbuilder and Visual Basic all make a programmer easily 100 times more productive than languages like Cobol. So why aren’t we building the same size systems today with 1/100th the staff?

The answer is left as an exercise for the reader.