Softwar

by Matthew Symonds

  Making sure that the Oracle database worked on the VAX (Virtual Address Extension) was a no-brainer for Ellison and Miner. The VAX (which made its debut in 1977) was the most impressive minicomputer to come onto the market, and all RSI’s intelligence agency clients were buying them as quickly as Digital could make them, while corporate customers saw them as being capable enough to take over at a departmental level many of the tasks previously reserved for mainframes. By 1984, more than 70 percent of the firm’s software license income was coming from Digital’s machines—the vast proportion from VAX seats. What was less obvious, but what rapidly became a key part of Ellison’s pitch to customers, was Oracle’s ability to run on just about every conceivable computer its potential customers might own.

  Portability, as it’s known, is the ability to “port” software to a given hardware platform. It not only meant that Oracle could sell to the widest possible market, it was also crucial for customers, the majority of which operated a heterogeneous mix of computers but wanted to have only one database. The architecturally elegant solution, and one that allowed Oracle to run on the dozen or so proprietary operating systems that were current, was to maintain a single code base and take the gamble of writing Version 3 of the software in a new programming language called C. Inexpensive C compilers (the software that translates a program into a form the computer can understand) were also becoming available for most of the machines that Ellison needed Oracle to run on. Ken Jacobs, who arrived at RSI in 1981 as employee number eighteen, says, “It was done at a time when the rest of the industry couldn’t even spell C.” Even today, Oracle is the only database that can run on all the main operating systems likely to be found under corporate databases, from Microsoft’s Windows through all the various flavors of UNIX to open-source Linux and MVS (Multiple Virtual Storage) on mainframes.

  By the time Version 3 made it out of the door in 1983, RSI had sensibly changed its name to Oracle Systems (later, Oracle Corporation) and was getting ready to move to an 84,000-square feet site in nearby Belmont. Much of Ellison’s time was spent talking up the relational model. Don Lucas says, “People just didn’t believe that the relational model would work. There was a great need to do a very high level sell and say, ‘Hey, this is going to be the thing and these are the things you could use it for.’ I’ll never forget being with some guy, an analyst, and he just said that relational will never work. It’s a toy, you know, fun and games. We had to fight that for maybe ten years. Larry was very good at this. He was like a spiritual leader, an evangelist for the relational database model.”

  While that kind of “high-level sell,” which included doing a lot of public speaking at conferences, suited Ellison’s talents, RSI/Oracle quickly needed more than just Bob Preger and Ellison to sell its product. Don Lucas had brought onto the board his friend John Clark, who had a background in sales. Ellison says, “He patiently explained the basics of sales to me. If you have a good product, the more salespeople you have, the more you’ll sell. If you want to sell twice as much, get twice as many salespeople. I said, ‘Really? It’s that simple? Okay, we’ll hire some more salespeople.’ And then we started getting these sales guys in and they just started to replicate, kind of like a virus inside of your company.” A virus? It’s an odd choice of word and one that indicates the ambivalence that Ellison has even today about the people he employs to sell Oracle’s products.4

  For the first few years of its life, Oracle grew rather slowly, by the standards of today. Jenny Overstreet, Ellison’s assistant and confidante for thirteen years, remembers that when she joined the company in 1983, there were only fifty employees in California. “Larry still thought that was probably about all Oracle was ever going to need.” In fact, by this time Ellison had already realized that Oracle had the potential to become something much bigger. The combination of Version 3’s (at least theoretical) portability and those replicating sales guys meant that sales were suddenly beginning to explode. Ken Jacobs says of Version 3, “It was a vision of what could be done. One of the most gratifying things was the tremendous faith of our early customers who stayed with us through difficult times. For many of them it was like going through one of those shared experiences when a couple faces death but they survive together.”

  One of the smartest and most driven of those first salespeople was a young Mormon named Gary Kennedy, who had started up a midwestern sales operation in 1982. Among his first hires was Sohaib Abbasi, a quiet-spoken Pakistani who has run Oracle’s tools business for the last decade, and Tom Siebel, who went on to found Siebel Systems. Abbasi recalls, “The technical press was saying at the time that the relational database would never be useful, and even IBM had raised doubts as to whether it would ever be suitable for transaction processing. Our job was to call up prospects and tell them that if they would give us a day we would come and show them what the technology was capable of. We’d show up in the morning, they would explain what their system was—obviously everything was custom applications back then—and what they wanted. I had to build it in front of them.”

  It was a formidable team. Abbasi and Siebel were both highly qualified computer scientists who had even written theses on the relational model, while Kennedy, despite his intense religious convictions, was about to become perhaps the most aggressive sales manager in software history. In 1984, Ellison was sufficiently impressed by Kennedy’s efforts to put him in charge of the entire eastern half of the United States, and a year later he made him national sales manager. On the eve of Oracle’s initial public offering in 1986, when Kennedy was thirty-two and a Mormon bishop, Ellison made him vice president of U.S. sales and service.

  While a U.S. sales organization was being created, Ellison realized that Oracle could expand overseas without significant investment by doing deals with distributors. Two teams were signed up, one for continental Europe—Tom Peddersen Associates—and one in England, the U.K. arm of CACI, a famously tough systems integrator and consultancy. Over time Oracle bought out its distributors, but with a minimal initial outlay it began to build an international presence that also brought in funds when the product was immature and the money was desperately needed. Peddersen’s friends Bo Ryden and Brian Cassidy became the founders of Oracle Europe, while CACI’s Geoff Squire, a highly accomplished computer industry executive, left to run Oracle UK. For several years, Oracle’s sales grew faster overseas than in the United States. Ellison says, “The salespeople we hired in Europe were very professional and service-oriented. The European management team’s strategy was to build long-term relationships with our customers and do business with them on a regular basis. This European ‘farming’ strategy was in stark contrast to the U.S. sales organization’s ‘hunting’ strategy. U.S. salespeople tried to sell the largest possible transaction to a given customer and then move on to the next customer and the next deal. It took me until 1991 to figure out that the U.S. hunting strategy was both shortsighted and unsustainable. It took another decade to change the culture of the U.S. sales force from hunters to farmers.”

  The responsibility for building up the U.S. sales organization fell first to Mike Seashols, a confident and highly competitive salesman who, like Kennedy, was religiously devout. A member of the intensely evangelical Covenant Church who read the Bible every morning before going out to do battle, it was Seashols who recruited Kennedy, while Kennedy hired other super salesmen, such as Siebel; Greg Brady, who went on to found i2, the supply chain specialist; and Craig Conway, who became CEO of the ERP vendor PeopleSoft. Seashols was fired by Ellison and replaced by Kennedy in 1986 for reasons that remain obscure. Seashols claims that he had expressed discomfort with some of the statements in the company prospectus that was circulated to investors before the public offering. Others suggest that he wasn’t making his numbers, which is difficult to believe given that Oracle’s U.S. sales were pretty much doubling every year while Seashols was responsible.5

  One possibility is that Ellison had concluded that he wasn’t hungry enough. Seashols
recalls a dinner with Ellison: “It was right before we went public. Larry asked, ‘What are you going to do with all your money?’ I had no idea. My house was paid for. I was driving a new car. I didn’t have any needs I could think of. I said something about just wanting to be content. I think that really took him aback.” That said, Ellison was still not giving much of his attention to what was or wasn’t happening in sales. As far as Ellison was concerned, overwhelmingly the most important contribution he could make to Oracle’s success was to concentrate on making the product better. He simply didn’t regard himself as competent to concern himself with all the other things that a CEO is supposed to be responsible for. To some at Oracle, Ellison’s approach was one of enlightened delegation. “You could say that,” he says. “But it was closer to abdication than delegation.”

  In fact, Ellison had every reason to concentrate on the product. Mike Stonebraker had taken the Ingres relational database project he had overseen at the University of California at Berkeley and formed a company around it called Relational Technology, Inc. Although a commercial version of Ingres had come to market a little later than Oracle, Stonebraker’s outfit was growing faster than Ellison’s. In 1984, Oracle’s sales had doubled to $12.7 million, while Ingres, as RTI was increasingly known, had tripled its sales to $9 million. Ellison says, “They were really kicking our butts. They were catching up fast because we had just rewritten our database product and we were having software quality problems. Sound familiar?”

  The Berkeley team at Ingres had had much more time to refine their user language, QUEL, than Oracle had to develop SQL, and many relational experts thought it was intrinsically a superior language. Ellison says: “Maybe QUEL is better than SQL. Maybe French is better than English? It didn’t matter: English and SQL were going to win.” What Ellison was most worried about was the sheer engineering talent at Ingres. “It had become painfully clear to me that our development organization wasn’t good enough to keep up with the team at Ingres. So we had to rebuild it. If Stonebraker was hiring the best kids from UC Berkeley, we would hire the best kids from CalTech, MIT, and Stanford. We would also recruit the very best experienced programming talent in the Valley. In a real coup we hired a superb team from Xerox PARC. One of those guys, Derry Kabcenell, was among the most important people ever to work at Oracle. Thanks to Derry and the new engineering team he led, we overcame the software quality problems in Oracle Version 3. He delivered a superior database product—a product we could be proud of—a product that would kill Ingres. We called it Oracle Version 4.”

  Kabcenell now works at Oracle only part-time, but he still contributes his ideas and experience to major software architecture projects. He’s a slightly built man who talks softly with an almost professorial air. The thing that he remembers most vividly about his hiring was the speed at which the little company was recruiting—a friend had joined in January 1983, when there were about thirty people on board, but by the time Kabcenell arrived in September the number had grown to seventy—and the intensity of his interview with Ellison. “I was really impressed at his grasp of the technology and also his respect for the professional practice of programming. I was doing a pretty extensive set of interviews with different companies and had a chance to meet a bunch of people, including CTOs. Nobody I’d met was as addicted to technology as Larry was. In my interview he described a feature that was just being developed in the database that’s still important today called ‘read consistency’—he described that to me and asked what I thought about it. I was just amazed that I was having that kind of conversation with the CEO the first time I’d met him.”

  It was a technique that Ellison used with all the recruits to the development team; it made them want to work for Oracle, and it ensured that he was hiring only people who were smart enough to debate technical issues with him at the highest level. Andy Mendelsohn, like Kabcenell a graduate of MIT, who joined in the same year, remembers, “In the interview with Larry I was very surprised by the technical level of the questions. He discussed different ways to use indexes to resolve results from a SQL query. It was a real detailed kind of thing, but it showed me that he actually understood the technology.”

  Hiring people such as Kabcenell, Mendelsohn, and another recruit from the same year, Roger Bamford, was the only way that Ellison believed Oracle could have a future. Eighteen years later, nearly all the people that Ellison brought into the engineering team at that time are still at Oracle and are still, despite middle age and huge wealth, involved in cutting-edge work on the latest versions of the Oracle database. For all the company’s reputation for revolving doors in the executive suites and a hire-and-fire culture in sales, the people responsible for creating and developing the core product, known within Oracle as the “kernel group,” have been an extraordinarily loyal and stable team. While many parts of the business actually need staff turnover to stay fresh and vigorous, Ellison believes that keeping the elite kernel group together has been vital. The process of building a software product teaches a programmer what to do and what to avoid. The accumulated knowledge and experience within the forty- or fifty-strong kernel group comes from continuous work on improving the core code rather than from some extension of the product that will make a flashy new release.

  Derry Kabcenell’s impact at Oracle was immediate. Ellison says, “The first version of our database, Version 2, was a good working prototype written in PDP-11 assembly language—the same language that I wrote the earlier CODASYL database in. Version 3 was totally rewritten in C. It was much bigger and more complex than Version 2 and, as a result, plagued by quality problems. Derry made Version 3 work by going around rewriting other programmers’ code and fixing their bugs. One of our programmers had been working on a problem for six months, and Derry, bless his heart, just came in one weekend and rewrote the whole thing. Of course it worked perfectly. Derry combined brilliance with discipline and endurance. It’s a rare combination. Of course he had perfect grades at MIT. Derry’s not a perfectionist—he’s an obsessive perfectionist. Sometimes his thoroughness went over the top. I remember when he was buying a condominium, he told me that he had carefully read all twenty pages of the sales and owners’ association contracts. He read a law book to make certain he fully understood what he was signing. Several years later Derry confided in me that he was worried that his brain might have filled up because his memory was not as good as it used to be. I told him it was his own fault for cluttering up that wonderful brain with all those stupid condominium agreements.”

  As well as ensuring that Oracle had the talent to compete with Ingres, Ellison made sure that the development team was building the right things. “If we built the right products the right way, we would win. That was my view of the world then, and that’s my view of the world now.” Ellison bridles at the suggestion of some former colleagues that Bob Miner was running the development team while he was out selling. “I loved Bob. Everyone did. He was an uncommonly humane, generous, and caring person. But his egalitarian nature prevented him from ever crossing over from labor to management. He loved being one of the guys too much. He wouldn’t give that up for anything—certainly not for money or fame, neither of which interested him much. So Bob became the head of the ‘Oracle programmers union’: shop steward, and father confessor. He was the moral and spiritual leader of the engineering team—of the entire company, really. He was the guy you went to if you had a personal problem. When the person I considered our worst programmer lost half his Oracle stock in a divorce, Bob thought the company should make it up to him. I had wanted to fire the guy for years. Bob wouldn’t allow it. He protected his people like a mother bear. While I couldn’t fire any of his people, Bob was perfectly happy to let me recruit the new members of the programming team, which I did, and manage the development process.” The kernel group veterans I’ve spoken to bear out Ellison’s claim.

  Very often, Ellison would say that something was in the database that hadn’t yet been done. After Version 2 had come out, he w
rote a little spiral bound book describing Oracle and the SQL language. He says, “Someone jokingly said, ‘It took us eight years to make the database product look like your book.’ Not exactly true, but what is important is that we were making steady progress and we were ahead of the competition—most of the time. The database just kept getting better and better.” If Version 3 was all about portability, the most significant feature of Version 4, which came out a year later, in 1984, apart from the all-important reliability that Derry Kabcenell had given it, was “read consistency,” or the assurance that a query against the database will read a set of data that remains consistent during the time it takes to execute the query. For example, money being switched between bank accounts during a query could not be miscomputed, and employees being added to an HR database not be counted twice.

  With the solidity of Version 4 and Oracle’s increasingly aggressive sales force, Ingres was hard pressed to maintain its momentum, but the real threat was the decision of the American National Standards Institute (ANSI), supported by IBM, to declare SQL the standard relational database language. Mike Stonebraker of Ingres didn’t even bother to show up at the committee meeting to make the (quite strong) case for adopting QUEL because he was ideologically opposed to setting technology standards. It was the behavior of an intellectually arrogant academic rather than a prudent businessman protecting the interests of his company. Ellison says, “Stonebraker invented QUEL and stuck with it like a proud father, while IBM and Oracle supported the SQL standard. Lack of SQL support hurt Ingres badly. But so did lack of portability and read consistency. And Ingres had fallen far behind in performance. All this together conspired to kill off Ingres as a competitor in the database market.”

  No sooner had that threat of Ingres been diluted than others appeared. In 1985, IBM released a relational database for big mainframes called DB2, but it was part of the process by which SQL became a standard, and Oracle did only a small amount of business on mainframes anyway. Two newer rivals, however, were determined to grab a large part of Oracle’s fast-growing business. The lesser of the threats came from Informix because of its concentration on the nascent UNIX market. Although UNIX would become the enterprise server operating system of choice in the 1990s, at that time it was more popular in the universities than in corporate computing environments. Sybase, on the other hand, came from nowhere to become a dangerous competitor.