Why the operating system is obsolete - speech by Sybase Inc. VP Robert S. Epstein at Personal Computing Forum 1990

Esther Dyson, EDventure Holdings: [In Russian] Good morning. This is the day for the plumbing. It's also a day we have a somewhat smaller audience so we can get more technical. Bill

Gates is out there rewriting his talk, and he wants to know how to improve OS/2 and Dynamic Data Exchange. Bob Epstein is going to explain why the operating system is obsolete and why Bill should be rewriting his talk. For those of you who haven't heard him before he's really terrific. For those of you who have, he's got new material.

[Applause]

Robert S. Epstein, Sybase: Nobody likes to speak at 8 a.m. and be the first speaker. Last year Esther arranged some entertainment before my talk which woke everybody up. Since there wasn't any this year I thought I'd do a quick quiz. I have a joke that's so complicated you'D understand it only if you're wide awake. What is an agnostic - hang on, I have to try it again. What does an insomniac, agnostic dyslexic do? He lies awake at night and worries whether dog exists.

[Laughter and applause]

Dyson: We're awake.

Epstein: All right. Good. I'm excited. I've been thinking about Danny's talk and was trying to create an analogy to my talk. About three months ago when I started working on this talk, I had a hard time figuring out what to say. Last night I used a Thinking Machine. What we used for the generator - people use sex for the new generation - was the pc industry. What I used for the parasites - and I want to put that in the most positive sense - was the mainframe industry. What's happening is we are attempting to migrate the pc industry to the mainframe industry's satisfaction so that we end up with one unified industry. I'm calling that the on-line enterprise. I thought I made up a buzz word, but I found out I'm months too late, because somebody else coined the phrase.

What I really want to talk about is why the operating system isn't the issue. In the last couple of years it seemed to be the whole focus and that's a mistake. Not that operating systems are obsolete in the sense we wouldn't use them, but rather they're not what's going to drive the industry.

I divided the pc industry into three environments. Historically it's been a company's standalone environment, typified by DOS, Macintosh, standalone single applications. Today the dynamics of that part of the industry are at an all-time low and little change is occurring. Groupware - a term I've never understood - is the next step but won't change much of the industry dynamics. The real change that will make OS/2 and UNIX take off is the on-line enterprise. It win represent major growth in the industry, although the marketplace hasn't spoken yet on it.

On-line enterprise is a merger - the Danny-style merger of end-user computing and production systems into one unified system. Traditionally pcs have been standalone and separate from the production systems. This system integrates them. Client/server technology is one thing that enables this, but there are tremendous psychological barriers to overcome. For example, in 1987 the fastest machine we ran on did transactions in the mid 20s, and was half a million dollars. With the release of Version 2.0 of OS/2 this year, we'll be at the same performance level on our lowest-priced machine and software. By 1994 what we like to think of as the pc industry win produce machines that are 3090 class in terms of performance.

This is causing a major shift in the industry. Taking advantage of it is going to be the key. One of our customers is doing client/server computing and on-line enterprise planning. Their goal is to accomplish standardized server functions built for one application that could be reused by many applications. They have a customer server that keeps track of all the orders which have been placed. In something interesting called the SeatSaver, they can display an auditorium and available seats. People can reserve them, but it's an imprecise server in the sense that until somebody really does the seating, the seats are only temporarily reserved.

You send the Visa authorization server a message. It processes the Visa electronically. A ticket server prints the tickets. A FAX server sends the FAX. A custom application talks to all these servers to automate the job, but there's no reason why a spreadsheet or word processor couldn't be used as the user interface talking directly to all these servers.

A heterogeneous world

It's very important to realize this environment is not homogeneous. There are lots of different types of computers. We have another customer whose customer server is a System 38, so we have to tic into a fairly old design of a financial system. If this is the world, the on-line enterprise world will add a lot of value to our customers. How arc we going to get there and quickly? This, not operating systems, is what we need to focus on to get into this client/server world. The same operating system won't be on all the platforms. It's a given that it's a heterogeneous world.

Value-added is the second point. When it comes right down to it, of all software components the operating system adds the least value for the simple reason that it's the most removed from the application. It's the farthest distance from the developer. The other point which I find fascinating about operating systems is they're gradually reaching the point of total parity. POSIX requirements from the US government say all operating systems must have certain functions built into them, or they can't be sold to the government. A strong standardization if there ever was one. POSIX requirements make all operating systems look almost identical if you use only those functions, which are a fairly rich set.

Another troublesome example is IBM's SAA. Recently I listened to a couple of IBM executives explain SAA as an attempt to have four operating systems all look identical to the programmer. If that's true, it says there's no value-added among the four systems. This is a revealing point. Our industry is primarily in the business of adding value to our customers. We, can do that in a several different ways. We, can lower costs, allowing them to downsize by using faster, less expensive machines to run, not just analyze, their businesses. Secondly, we can make them more competitive. That's really the key. A lot of these people aren't just interested in saving money. They want to put their competitors out of business through better use of information or quicker implementation of a new idea.

Plumbing vs. understanding

How can we add value to our customers? Client/server architecture holds the key to the issues, which are how clients communicate with each other between the applications, how they go from one application across the network to another machine and how they communicate with servers. A lot of this was alluded to by Mitch yesterday when he talked about AppleEvents vs. DDE. When Application I talks to Application 2, it's likely to be in an operating-system dependent manner since they're both on the same operating system. But all of the rest are likely to be in a more abstract manner - something that's not dependent on the operating system - because so many different operating systems will be involved.

Some of the issues here are what I'll call the plumbing vs. the understanding. The plumbing mechanism is just to make sure this is possible at all. The understanding mechanism means we can understand what they're trying to do when they communicate. The other thing to determine is the real recipient of this communication. Is it a programmer reading a manual? Or is it another program trying to understand how to communicate? The operating system industries all endorsed various flavors of remote procedure calls. The database industry is starting to do the same thing. One way we differ is that we do a procedure called a database. It's through a dictionary so there's an inventory of all the procedure calls, what they mean and how to use them. When you do it through the operating system, that content is lost.

As for client architecture and what's going to matter, although I've left off a number of layers, the major layers are the operating system, which then sets up different types of engines: a local engine; an inference engine; a computer engine that could be a spreadsheet; a graphics engine; and a presentation tool kit. On top of all this is some application development environment.

Rather than Esther learning an application program other XyWrite, it may be that she stays in that environment completely. Give end-users what they're used to with a single environment. Increasingly, the end-user will not be able to tell what operating system they're running on.

If you look at the server architecture, there's almost nothing there. There's an operating system and communication, then different classes of servers: communication servers; my all-time favorite database servers; file system servers; something we'll call environment-specific servers because application-specific servers create an acronym which won't be very successful from a market viewpoint; and dictionary servers, probably the key component in that. What we're trying to do with all this is provide a lot of productivity. By having servers with high-level programmability, you're making them very powerful. The role of object orientation is to say, "Let's put in those servers dictionairies that describe what's happening in the system." They're complete object dictionaries. Our goal is to eliminate the need for doing client programming. In an application you can look at the various objects on the network, pick the ones of interest to you and have it generate the majority of the application for you. The programming fills in the exception details.

The Three Faces of the Server World

Let me present three views of the server world. From the database perspective, the world;s mostly a big database problem and there's a little bit of communications and operating systems going on. For example, we have a product for building servers. It allows you to talk to the database and to a network. This year we're adding a third model so you can do multi-tasking as well in a way that's portable across all operating systems. From my viewpoint I could say that we try to sell databases and we give away little bits of operating system and network.

The operating system vendors have a different view. They say nothing is more important than the operating system. Of course you need a little communication and you may need to run a database on top. The newer release of OS/2, for example, has all these attributes so you can store with the files the descriptions of what they mean. What happens when there are tens of thousands of these descriptions? They'll need to add indexes, and they'll need to add some database functions in order to do it. They're viewing the world as one in which you add in bits and pieces of database to make these things interact.

The third view is that of the network companies which say the network is the operating system, but you may need a database on top. Everyone is approaching this from a slightly different perspective. I don't know how it all will resolve itself. In trying to summarize it to give you something to think about, I made the classic mistake, which is to overlook the customer view of all this. There's the Visa card server. They don't want to know the details about how all this works, so whoever gets in there the quickest will be the one they spend the most energy on.

To summarize, what's happening is what I like to call the vendor-independence pyramid. At the bottom of the pyramid are the hardware ABI consortiums. Very few companies are still in the business of producing unique machines that only they manufacture. Rather they're all trying to do standard binaries on a certain class of machines. How will they add value? What they can do is modify the price-performance curve. They can have a higher reliability. They can have better operational controls. That's how a NetFRAME will differentiate itself from a SystemPro, for example.

The next layer is the operating system companies. The only way for them to add value and differentiate themselves is by the amount of software that runs on the operating system and, of course, performance. The next level is the network companies. They're going to provide more performance and operational controls and network management. The database companies are next. We'll give operating system independence; we'll give hardware independence; we'll give dictionaries to run it. We're closer to the application so we're getting closer to meeting what it is that you're trying to do. At the top of the pyramid are the application companies. Either they will have exactly the application you need, in which case you should buy it. Or they'll go on-line and say, "We'll give independence from the database companies because our applications will be portable across multiple databases."

We're all in a different business of adding value. On-line enterprise is the thing that will provide more growth for the industry. One of the key trends is the need to be able to build programmable environment-specific servers and include object and process dictionaries into the servers. Another trend is the increasing use of integration services. Very few people know how, and we're going to be in the business of teaching our customers how to do this until they're independent on their own.

Increasingly, people will look at two different pieces of software or hardware and will measure them by their true value-added with respect to the application. In that role, high-level functions, communication functions and interoperability databases increasingly will play a very important role. The industry will shift more to focus on how those work and less on the operating system. Thank you very much.

[Applause]

Dyson: Thanks a lot. That was a wonderful exposition of what we're going to be talking about the rest of today.

COPYRIGHT 1990 EDventure Holdings, Inc.
COPYRIGHT 2004 Gale Group