October 28, 1996
By John Tibbetts and Barbara Bernstein
Guess by now you've heard the bad news about client-server-it's on the ropes, apparently, publicly discredited and virtually friendless. The trade press, which once led the client-server fan club, prints client-server obituaries almost weekly. Those fat-client applications have cost too much and proved too hard to manage, we're told; make way for Web-enhanced intranets instead.
There's an inherent contradiction in the notion of the World Wide Web "replacing" client-server. The Web represents the single most successful adaptation of client-server architecture on the planet. It single-handedly vindicates the concept.
There's irony here, too. The technology that finds itself under siege today was, a few short years ago, gleefully inflicting the same ignominy on mainframe technology. Those "obsolete" mainframes are now resurgent, as the client-server systems that were supposed to replace them have failed to live up to expectations. Fifty percent more mainframe Mips were shipped in 1995 than in 1994, and the margins are even more pronounced for disk access.
While much high-minded architectural dogma has been spouted, it's now clear that the real reasons behind the market stampede to client-server have been quite mundane. Worse, they have been based on erroneous assumptions and short-term advantages.
The first reason was economy. In the early 1990s, both the trade press and business press were fond of reporting that replacing a mainframe with client-server could mean savings of 90% or more. But it should have been obvious that when you decentralize your system, you decentralize your costs as well. The cost of managing clients turned out to be astronomical, and client-server has ended up being no bargain at all.
Yet many corporations were willing to absorb the higher costs because of client-server's second apparent advantage:the graphical user interface. If you wanted to give your application a GUI, with all the ease of use, productivity gains, and fashionability that a GUI represents, client-server seemed, for a few years, the only way to go. But now that the Web has brought graphical interfaces to all sorts of platforms, including big iron, many people who switched to client-server for that reason are wondering what they've done.
A Second Look
Now that the cost and user-interface sidetracks no longer cloud the popular view of client-server architecture, perhaps we can evaluate it as an architectural platform that's well-suited for some uses and disastrous for others. No matter what the obituary writers say, most future systems will include a client-server component.
As an enterprise architecture, client-server may finally resume its rightful role. The smaller database or object server that people usually think of when they say "client-server" works best in departments or workgroups where you want local ownership of information assets, where the management requirements of these assets are compatible with the organization's charter, or where you need such fast access to these assets that you're willing to pay to keep them coordinated. When information assets have to be shared among many seats or many sites, when these assets need to be kept closely synchronized, or when you need centralized management of them, there's no substitute for a superserver or mainframe.
Pendulum swings are probably inevitable in our industry, but the client-server boom and bust has been absurd. It was based on a superficial understanding of distributed architectures, exacerbated by vendor claims, and perpetuated by pack journalism. Perhaps we'll be more sophisticated this time around.
John Tibbetts and Barbara Bernstein are partners in Kinexis, a San Francisco consulting firm. They can be reached via E-mail at kserver@kinexis.com.
Copyright ® 1996 CMP Media Inc.