Softwar

by Matthew Symonds

  Oracle, by 1994, barely three years after so nearly self-destructing, had conclusively triumphed in the vicious database wars, in large measure thanks to Ellison’s incredible competitiveness and strategic brilliance. But the same could not be said of the applications business that was supposed to become the main driver of the company’s growth as the database market matured. Applications would become Oracle’s and Ellison’s crucible.

  * * *

  1. LE writes: I wanted a deal; I just didn’t want to give up any Oracle equity, so I slowed down the negotiating process. Time was on our side. Every day our cash position got stronger, so our negotiating position got stronger.

  2. LE writes: From the first day, I found Jeff very easy to work with. He says exactly what he thinks. He has no personal agenda at all. He’s fiercely loyal to the company. He looks out for the interests of our shareholders, employees, and customers. And he’s a leader. As they say in the military, it’s been an honor to serve with him.

  3. LE writes: I thought then and still believe that a good consulting manager is ideally suited to sell complex software products. Ray could sell the business benefits of our technology. That’s what we needed to do more of in our field organization. And of course Ray could improve our consulting service delivery. He was the right guy for the job.

  4. LE writes: Robert Shaw was a great addition to Oracle. He deserves most of the credit for building our consulting organization in the United States. He’s also a pretty good sailor.

  5. LE writes: I don’t think Craig was or is, as Ray put it, a “bad apple.” The fact that Craig managed a turnaround at PeopleSoft proves he’s a very capable software executive. But Craig was not Ray’s guy. Ray wanted people that were totally loyal to him.

  6. LE writes: I didn’t agree with Ray’s decision, but I didn’t overrule it. Ray had to build a management team he was comfortable with. It was clear that he and Craig didn’t like each other.

  7. LE writes: Interestingly enough, the sales force eventually wore Ray down and he started paying them for selling consulting services. It was fascinating watching Ray interact with our sales force over the years. Sometimes he changed them. Sometimes they changed him.

  8. LE writes: It’s true. I wanted to knock out Sybase while they were technically behind and vulnerable, even if it meant sacrificing profits in the near term. If we were successful, the profits would be greater in the long run.

  9. LE writes: If you work in Silicon Valley long enough, you can’t help noticing how much the technology industry resembles the women’s clothing business. Both are fashion-driven. Fashionable ideas are hot, while the others are not. In the early ’90s, VOD was fashionable and everyone—Oracle, Microsoft, Sun—was doing VOD. These days “Web services” are hot, so everyone is doing and talking about Web services. If you are out of step with the latest fashion in the tech industry, the tech analysts say nasty things about you and you don’t get your picture on the cover of magazines.

  7

  BEST-OF-BREED

  When Ray Lane arrived at Oracle in the middle of 1992, the still relatively young applications business that Jeff Walker had founded six years earlier was growing fast. Its first products might have been thin on features and bug-infested, but by the early 1990s Oracle had nearly 1,500 customers, made up of mainly fairly small or midtier American companies, running their financial, human resources, and manufacturing packages without too many complaints.

  Lane says, “Walker was brilliant. He created some very innovative things in those applications and he used Oracle’s technology better than either SAP or PeopleSoft. The customers were happy, they liked the innovations, and they bought them because they were open systems, whereas every other application company’s at the time were all closed and proprietary running on mainframes or minicomputers.” What Lane meant by “open” was that Oracle’s apps were built on the UNIX operating system and on the relational database—two major differentiators from the competition that, moreover, a sales force used to selling databases understood and felt comfortable talking about.

  Lane believed that these qualities, combined with the rapidly expanding consulting organization that Robert Shaw now had a mandate from Ellison to build, would ensure growing success for Oracle’s applications. There was a lot riding on it, given that nearly everyone at Redwood Shores, even Ellison, to some extent, believed that the database market was fast maturing. Oracle might never get back to doubling its revenues each year, and it was too big for that anyway with sales running at $1.2 billion for the 1992 fiscal year, but the combination of applications and consulting would ensure that Oracle recovered and held on to its status (and its stock rating) as a growth company.

  However, for anyone who wanted to look problems were already beginning to build up in applications. Unlike Ellison on the database side of development, Walker had not stuck to a policy of hiring only the best and brightest. Ellison says, “Jeff wanted people who were totally loyal to him and his ideas. That made it hard for him to hold on to the best people.” Ed Screven, who worked with Walker, says that he was a bully who had favorites while picking others out for vilification: “I mean, the guy literally made them cry.” The consequence was that when Walker was fired, he failed to leave much talent behind him. Screven says, “We had a series of very poor managers who were no good at building a competent engineering organization.”

  Part of Walker’s legacy that stored up trouble for the future was that he implemented his own tools. Oracle’s own tools operation under Sohaib Abbasi was concentrated on going after the market for building customized applications for the database. In other words, Abbasi was creating tools to leverage the database as it evolved from host-based computing to client/server, while the tools in applications were stuck without a migration path to the new platform. The consequence was that Oracle’s applications were not rewritten to run in client/server mode until 1993, and even then Oracle’s tools proved extremely difficult to adapt to the kind of graphical user interface (GUI) that PeopleSoft was making popular and that customers expected to find on their Windows desktop PCs.

  To make matters worse, in 1992 Ellison and Abbasi had taken a fateful decision to extend Oracle’s portability proposition to supporting as development platforms a wide variety of emerging graphical user interfaces. The list included Windows, Apple’s Macintosh, IBM’s OS/2 Presentation Manager, OSF’s Motif, and Sun’s Ultimate. The decision was based partly on what had worked for Oracle in the past and partly on not wanting to give too much of a helping hand to Microsoft by betting more strongly on Windows. However, as Abbasi says, “The pressure was on me to deliver technologies that would enable portable user interfaces, but it was much more difficult than we expected and original estimates were off by two or three years, but by then the market had already determined that Windows would be the dominant GUI. It ended up being a very expensive decision.”1

  What both of these costly mistakes showed was that Oracle’s technology development was being driven almost entirely by the requirements of the database rather than the applications business. Not surprisingly, as by his own admission Ellison was barely thinking about what was needed to help applications. He admits, “I paid no attention to the goings-on in applications. I was a disinterested bystander.” The truth is that Ellison found applications and the mainly clerical functions that the software of the time was designed to automate unspeakably dull compared with the intellectual purity of the mathematics and physics that were at the heart of database development, never mind the glitz of Hollywood and interactive television.

  Ellison’s neglect meant that Oracle’s applications were in no shape to respond effectively to what was about to hit them. It was called R/3. In 1992, the German software powerhouse, SAP, which had been founded by five former IBM systems engineers in 1972 (it stands for Systemanalyse und Programmentwicklung—Systems Analysis and Program Development), had at last announced a client/server version of its R/2 applications suite. Launched in 1979 after several years of
painstaking development, R/2, which ran on mainframes, was widely recognized as the most complete and thoroughly engineered of the new breed of packaged applications. Typically, SAP hadn’t skipped to the new client/server paradigm with great speed or nimbleness. But it had done so with precision and meticulous planning. At the same time as R/3 was being developed, SAP was also preparing a serious assault on the largely untapped U.S. market, with SAP America establishing a development center just a few miles from Redwood Shores in Foster City.

  For Oracle’s applications, R/3’s arrival in 1993 was a disaster. Ray Lane says, “R/3 changed the game. Although we’d had some success in that area, we weren’t really an application company. Our sales force and our consultants didn’t really understand how to compete in the applications business.2 They had been able to sell saying ‘open’ and ‘relational,’ just like when they sold databases. But when R/3 came along, it took that advantage away. We now had to fight on a different battleground, and that was business functionality. No contest. We didn’t even come close. Against SAP, we were a fraction. So we went on what turned into a four-year binge to try and catch up with SAP. From 1993 through to 1997, our entire application effort was devoted to trying to build the features to compete.”

  Lane realized from the outset that competing against SAP would be very difficult. SAP had slowly spread from its base in Germany to one European country after another, adding localization and translation as it went. By adding the features that American companies needed, it was able, at a stroke, to double its potential market. For Oracle, it was the other way around. Lane says, “We didn’t have Italian accounting, say, or German manufacturing. To double our market size, we had to go to twenty-seven different countries in Europe.” Nor was it just a case of not being able to attack local markets in which SAP was entrenched; for any global business with operations across many borders, Oracle in 1993 wasn’t even an option. While SAP could aim for the biggest and most profitable accounts, Oracle faced being left scrabbling for smaller customers, which were now in SAP’s sights because unlike R/2, which could run only on mainframes, R/3 would work on just about any computer.

  Nor did Oracle really understand just how different the applications business was from selling databases. The Oracle sales force wasn’t used to dealing with senior management, nor did it have the expertise about the requirements of different industry “verticals,” such as energy or financial services, how customers ran their organizations, and therefore what functionality was likely to be most important to them. Lane says, “SAP called very high. They called at the boardroom and the CEO, and our guys are used to calling at the CIO and down—talking about technology with database administrators.” Jeff Henley says, “Even today, it’s hard to get some of our sales force to move beyond the CIO, because that’s where they get their meat and potatoes—learning how to sell to a financial guy or an HR or a sales guy or whatever is a big challenge.” Over the years, Oracle has struggled with this issue, with some, including Ellison, arguing that there ought to be separate sales forces for the technology and applications products.

  Nor was it clear whether Robert Shaw’s aggressively expanding consulting empire was helping applications or not. It helped to the extent that Oracle was, as Shaw had promised, gaining a great deal of knowledge about integrating Oracle’s products. Ellison believed strongly then, as he does now, that for plenty of customers the direct model, in which a single vendor takes responsibility for building a solution, is attractive. However, even by 1994 it was becoming apparent that there were significant costs to the way Oracle was going about building its consulting business.

  SAP had carefully nurtured relationships within the Big Five consulting firms, especially with Andersen Consulting, the largest systems integrator in the world. When companies were deciding whether and how they were going to implement an ERP system, they rarely started off by talking directly to the software vendors. Instead, they would ask one of the consultancies, usually one with which they had an existing relationship, to evaluate their business processes and then recommend the software that would best fit their requirements.

  Although SAP’s suite was far from perfect—it was notoriously inflexible and hard to put in (not that that worried consultants too much, who were paid according to the length of the job)—most of the required functionality was in place and, critically, the consultants would not be pitching the software of a company that appeared intent on stealing their lunch. What’s more, a recommendation in favor of Oracle’s applications would run the risk of the customer then inviting Oracle Consulting to pitch for the work. It made choosing SAP a no-brainer. Jeff Henley says, “We totally screwed up partnering by building this big consulting group. We totally pissed off our partners.”

  Ellison, as he does so often, claims naïveté: “I wasn’t aware of how important the consulting companies were in recommending applications, because they weren’t very important making recommendations in the database market. I didn’t understand that building a big consulting business was making it much harder for us to sell our applications, so I supported building up our consulting business while SAP was off building alliances. We made very little effort to work with consulting partners.”

  Robert Shaw, unsurprisingly, sees it differently: “SAP obviously made the decision to go the other way from us with consulting. But you’ve got to remember, they were starting from a company that’s twenty years old in the business of applications. I think we lost some market share and penetration to SAP because the partners didn’t recommend our product but, at the same time, our product wasn’t ready for the Fortune 100 world that they inhabited. It didn’t have the globalization and a lot of the functionality it took, so we were probably better off losing that work. At the same time, as SAP grew and we grew, I think they came to be so dependent on the systems integrators that they were unable to compete with us when we moved to rapid implementation and single point of accountability.”3

  Ellison’s response to the threat from SAP was to appoint thirty-three-year-old Ron Wohl to clean up the mess inside applications and produce a package that would stand comparison with R/3 and PeopleSoft’s successful HR and financial packages. He knew that it would not be easy, but he had no idea what a bed of nails he was consigning his protégé to. Ellison, however, had huge faith in Wohl’s ability. He had handled the complicated negotiations with Nippon Steel with calmness and intelligence. Since then he had operated as Ellison’s chief of staff, and, despite often having to play the difficult role of go-between, he was recognized as technically very smart, straight to deal with, and utterly loyal to Ellison. Ellison believed that Wohl could build the kind of applications development team Oracle needed if it were to compete effectively with SAP—one that was both disciplined and talented.4

  The only problem was that Wohl knew very little about the applications business. When Ellison told the rest of the company that he was putting Wohl in charge, there was consternation and then anger. Ray Lane says, “When Larry put Ron in charge of applications, all of us were just shocked. He’d never run a large organization, never done any development of any consequence. He was a smart guy, but he knew nothing about applications, didn’t know our products because he’d lived with Larry. He was kind of a thinking guy. Very seldom do software companies succeed when they try and build a second front, a second product, and second market. This was going to be our big play—by the year 2000 this was going to be billions of dollars of revenue. So I said, ‘Ron Wohl, I don’t think so.’ I was probably negative from the very beginning on Ron Wohl.”

  From the outset, Lane seemed unwilling to understand the extent of the difficulties that Wohl was grappling with. The organization Wohl had been asked to take over was a shambles. Oracle had been late to client/server in both technology and applications, it had embarked on a disastrously flawed strategy in tools with devastating effects for applications, and much of the business functionality that had taken SAP’s much larger development team many years to complete wa
s simply absent. Yet within a year, Lane was denouncing Wohl as a failure.

  It’s possible that if Wohl had been a different type of personality, the relationship between himself and Lane would not have deteriorated so rapidly. Jay Nussbaum, who was running Oracle’s federal government operation, says, “At school, Ron would have been the smartest guy, but he doesn’t have street sense. He can outthink you and outpause you, but nothing comes back.” For Ron Wohl, read Ron Wall.

  Ellison says of Wohl, “The things that make him good—his analytical ability, his detail orientation, and most of all his caution before he makes a commitment—make Ron so different from Ray that it was a constant struggle for them to work together. Ray is the type of guy who believes when something needs to be done you do whatever is necessary and make it happen. Ron believes when something needs to be done you analyze it thoroughly so you understand exactly how it can be done—if it can be done at all. Ray manages by force of personality. He wills things to get done. Robert Shaw, an ex-marine, strongly shared Ray’s ‘can do’ attitude. Ron frustrated the hell out of both Ray and Robert. They’d come to him and say, ‘Okay, to get this deal done we have to promise this,’ and Ron would say, ‘Well, that’s nice, but we can’t deliver it.’ They hated hearing that. Ron was killing their deals. It drove them crazy. So Ron got nicknamed ‘Doctor No.’ Ray never saw Ron as someone he could do business with.”

  The frustration of Lane and Shaw over running a features race with SAP that Oracle could never win, and their inability to relate to Wohl, was understandable but not exactly helpful. They were in the front line, dealing with protests from the field, and were only reacting to the difficulties of delivering on the commitments made to customers. Tensions between the development and distribution organizations in software firms are almost inevitable. Sales and consulting think that developers sit in ivory towers, insulated from the real world of deals, implementations, and dissatisfied customers. They are the ones who suffer, above all in their wallets, when development is late in delivering anticipated functionality or when the products that do ship are buggy and unstable. For its part, development tends to believe that sales will say anything that customers want to hear to snag their fat commissions and then expect engineers to perform miracles to rescue them from the consequences of their overpromising. But at Oracle in the mid-1990s, the divisions and the factional warfare were beginning to get out of hand.