Softwar

by Matthew Symonds

  “So I had this radical idea: we type stuff into our applications; we should be able to get stuff out. I said it just like that. When we type stuff into our applications, it goes into our database. I know the data’s in there. We should be able to get it out—in a useful form. I wanted all our process automation systems to come with tightly integrated information systems. It’s so simple. What’s wrong with you guys? It took a while to dawn on me just how hard the problem was. Companies have so many systems, they can’t see the forest for the trees. Companies have lots of separate process automation systems, each with their own separate database. Simple example: Oracle had seventy separate HR systems, each with its own database. To find out how many people worked at Oracle, you had to look into seventy separate databases. If we had one HR database, we’d know. But we had seventy. Now, seventy HR systems cost a lot more than one HR system, so we were paying extra not to know. Why are we doing that? I felt like an idiot.

  “But it was worse than that. Our HR systems kept track of all our employees. Our sales systems kept track of all our sales employees. Because the systems were separate, every salesperson had to be entered into both systems. When a salesperson moved from one group to another, both databases had to be updated. The duplicate data entry was expensive, but worse yet, it often wasn’t done. The sales database might be kept up to date while the HR database wasn’t. So we had conflicting and inconsistent data. If we had one database that kept track of our people, we would eliminate the duplicate data entry and the inconsistent data. With all these separate databases, we were paying extra for inconsistent data—paying extra not to know.

  “We had hundreds of separate databases. You couldn’t ask any questions because your information was so badly fragmented. Your purchasing information was over here. Your quality database was over there. So it wasn’t easy to find out who your low-quality suppliers were. And all the problems seemed to have the same source: too many separate systems, too many separate databases. It really was a stunning discovery. All these separate process automation systems have to be integrated and sit on top of one database. Then and only then can we have a true information system. And we’ll save a fortune by getting rid of all these separate systems.”

  Mark Barrenechea, a chubby, confident young programming manager who had come to Oracle in 1997 to build a CRM development team, remembers the moment when the truth about the applications business first hit Ellison. “He asked a very good business question. He said, ‘How many employees at Oracle do we have?’ Because, logically, as in all complex networks, everything is centralized. He just assumed HR data was centralized. So he asked how many employees there were at Oracle. Ron replied, ‘Well, we’d have to put a data warehouse together. We’d have to go out and put a team together. We’d have to consolidate formats. Larry, in ninety days I’d give you an answer’ and the guy went off the wall. He said, ‘Why isn’t all this data in one place? We have the Internet now, right. We can consolidate this into one global schema.’ That was the spark.”

  Ellison continues, “Taking over applications at the same time we were moving our database and tools to an Internet architecture was serendipity. In a fairly short time the right application strategy became obvious. It was a horrifyingly big job; it wasn’t going to be a short ride. But then neither was building real application clusters—game, set, and match in the database business. Building all our applications around a single database—building a single integrated global information system—that’s game, set, and match in the applications business.”

  This was Ellison’s epiphany. It was not just a question of suddenly understanding how Oracle needed to go about developing its applications to make them both better than and different from the competition’s; it was also about how Oracle itself could become a different kind of organization and how Ellison could reinvent himself as a CEO. Ellison’s other realization, as he became increasingly involved in applications development, was that in trying to consolidate systems and get business intelligence out of them, just as much effort would have to go into better processes. Ellison says it was like a yin-yang diagram that shows how one opposite produces another: “Better information allows you to improve your processes. The more complete your process, the better your information. It’s a virtuous cycle.” All of a sudden, the things that he had always assumed were intellectually beneath him became very interesting indeed.

  Ellison shared his revelation with senior colleagues during a strategy meeting in March 1998 at the Hotel Nikko, a stone’s throw from San Francisco’s Union Square. Mark Jarvis, who became head of marketing a month later, remembers the occasion well. “We had the heads of sales for all the regions, the heads of consulting, Ray, Larry, the heads of development, and a few other people, including myself. The sales force started off by saying that in the database business we can beat anyone because we can differentiate ourselves, but in the apps business, whatever SAP says, we say. They didn’t have features to sell that you couldn’t get in SAP.

  “So Larry stands up and says, ‘You’re all wrong. We lose because clerical administrators don’t like our product. All these wonderful features you want are irrelevant because all they care about is the user interface and the number of keystrokes.’ Larry’s insight was to change the game by saying that instead of just talking about transactions we had to start talking about extracting business intelligence from our applications. Instead of talking about keystrokes to executives who never used the applications, we should start asking, Do you know this and do you know that about your business. The idea in marketing terms is to move up a ladder. If everybody else is on one rung of the ladder, you move to the rung above them with a different message. The next rung of the applications ladder for us was business intelligence, and we built a campaign around ‘Do you know . . . ? ’ Then, after six months, when SAP started talking about business intelligence too, we moved up the next rung and started hammering on the Internet. It was a very big turning point. Even before we had the products, it began to change our ability to compete with SAP.”

  Ellison’s excitement was almost unbounded. In his own mind, he’d not only worked out how to make Oracle’s perennially underperforming applications business into a winner, but simultaneously it had been revealed to him how Oracle could become a dramatically more efficient company and how the CEO’s job, which he had spurned, would now be worth doing. Better still, what would make it all possible would be leveraging the Internet and the thing that Oracle understood better than any other software firm in the world, the relational database. Nor was there any question of having to put reengineering the company onto a back burner because of the need to sort out applications. One would lead directly to the other. Oracle would become a giant test bed for its own software developers.

  And what better way to demonstrate the coming revolution than to make the much-maligned Ron Wohl responsible for putting Ellison’s idea into action? Ellison says, “I decided to make Ron our CIO. I said, ‘Ron, we’re going to test our new applications inside Oracle. I’m going to turn our entire company into a laboratory. If the applications are any good, they should save us a lot of money, and for the first time I’ll actually know and be able to control what’s going on inside the company.”

  Although Ellison had been touting the benefits of centralizing data for a couple of years and had been canceling client/server development right and left since 1996 in favor of Internet-related projects, the operational reality at Oracle was very different from the marketing message. While a few high-tech companies were seen as e-business pioneers—Dell and Cisco Systems, for example, had already gone quite a long way toward using the Internet to put key business processes online, including their customer service, sales, and supply chains—Oracle was a pretty good example of the pernicious effects of client/server computing, especially as practiced by a fast-growing global company with plenty of money to spend. Although some of the applications that Oracle was using were by now Web-based and everybody who worked at Oracle was co
nnected to the Internet and used e-mail, on its own that wasn’t making a lot of difference. Information was scattered across more than a thousand databases in different parts of the world, and every functional organization within Oracle had its own computer system, replicated, naturally enough, in every major territory.

  Ellison says, “We had hundreds of large server computers managing hundreds of separate databases. For example, every major country had six customer databases—one each for marketing, Web store, telesales, field sales, accounting, and services. So we had hundreds of customer databases. We had seventy human resources databases. We had ninety-seven e-mail databases. Data, data everywhere, and not a drop of information.” Oracle had no fewer than forty-three full-fledged data centers around the world, each one stuffed with computer hardware and each with its own IT staff maintaining the multiple systems.

  Gary Roberts, the executive Ellison would put in charge of sorting out its IT mess, recalls, “We were actually running in excess of 140 customized applications; in some cases, we’d bought third-party products to do some things that Oracle applications couldn’t do. When I told Larry about the number of servers we had around the world—two thousand in Europe alone—he almost choked. And that was just counting servers that were four CPUs or more. Part of the reason was all those customized apps. You have to have test environments and staging environments and of course the production environment itself. Larry had one question that set us all back on our heels: ‘We’re the second largest applications company in the world. How come we have so many custom applications? And if I need these applications to run the business, why aren’t they part of the product suite?’ We looked at each other: Yeah, that’s a damn good question.”

  One of the consequences of each bit of Oracle having its own computer system was that each one of them could make up its own mind about how it wanted to do business. Ellison says, “Every country invented its own business processes for marketing, sales, service, everything, and operated the way they deemed best. Everything was nonstandard.” Both Ellison and Lane had supported the principle of having strong, highly autonomous general managers in each country. But the combination of a high degree of decentralization, global scale, and the functional silos formed by client/server resulted in a structure that was very nearly unmanageable and that encouraged “appalling” duplication of effort. Ellison says, “We, like most other large corporations, had a feudal structure. We were organized like medieval Europe. I was a weak king surrounded by a bunch of strong and fiercely independent dukes. I would sit in my capital in California and make policy decisions—which the dukes promptly ignored.”

  Ellison’s favorite example of the way this system operated was the work of the supposedly powerful pricing committee. Chairing the committee, which sets prices for all of Oracle’s software, used to be a pretty thankless task. “The pricing committee was ‘responsible’ for deciding how much we would charge for our products—our new application server for example. So we’d do some competitive analysis—what’s IBM charging, what’s BEA charging, what’s Microsoft charging? How does our product compare? What are the market dynamics? After that we’d make a decision, say, $10,000 per processor.

  “We’d then produce an updated price list and send it across the hall to our global sales headquarters. Unfortunately, our global sales team had their own pricing people who felt they weren’t doing their jobs unless they did their own analysis and—for the good of the company, of course—corrected any pricing mistakes we might have made. They’d say, ‘Larry’s an engineer, what does he know about setting prices? We’re salespeople, we know about pricing.’ So they’d reset the price to $20,000 per processor and send out a pricing memo to our European headquarters in Geneva. Of course we had another pricing team in Geneva that redid the analysis and reset the price once more. They’d say, ‘What do Americans know about selling software in Europe? We’re Europeans, we live in Europe.’ So a team in Geneva decides that the right price for Europe is $15,000 per processor. They then send that price out to Paris, Munich, London. The same thing happens all over again. The guys in Germany ask, ‘What do French people in Geneva know about selling software in Germany? The right price in Germany is $25,000 per processor.’ Every country had a different price. It was crazy.

  “We had about two hundred people around the world involved in analyzing and reanalyzing, setting and resetting prices. It cost us a fortune in duplication of effort. It delayed the process and confused most of our customers—but not all of them. One day I get a call from one of our largest customers, located in the northeastern United States. He tells me, ‘Larry, we’ve decided to buy all of our Oracle software from Oracle Brazil.’ I said, ‘But you’re headquartered in Connecticut, Connecticut’s not part of Brazil. Why are you doing that?’ He said, ‘They gave us the best price.’ Shit. Everything is so duplicative and decentralized, the right hand doesn’t know what the left hand is doing. We’re competing against ourselves. This is embarrassing.

  “I realized that there were two very important things we had to do, neither of them easy. First we had to move as quickly as possible toward the ideal of ‘one company, one database.’ Then we had to complete and integrate our applications suite. That meant building application modules we didn’t have, like contract management and pricing quoting. If you have gaps in functionality, it’s impossible to completely automate the flow of data through a business process. If there are manual processes left lurking around your process automation systems, it means you have big gaps in your information systems. Incomplete process automation causes cost problems, quality problems, and delays. Incomplete automation is almost as big a problem as data fragmentation.

  “Take the flow of data between sales automation and order management. When the customer says he wants to buy one of our products, we send out a price quote and a contract. Creating a contract, quoting a price, sending out a contract, negotiating changes, and actually entering an order into the system were all labor-intensive manual processes. Process automation is just like a manufacturing assembly line. If you want to get the efficiencies of automated production, you have to keep the car on the assembly line and not keep pulling it off to do things to it manually. But nobody had built applications that completely automated business processes end to end, like lead-to-quote and order-to-cash. This incomplete automation problem meant that companies consistently failed to get the cost benefits they expected from the process automation they invested in.

  “To remedy all this, we had to automate every fundamental business process end to end. That artificial separation between applications products—CRM and ERP—had to be bridged, because the data process flow from lead-to-quote to order-to-cash spanned marketing, sales, order management, and accounting application modules. We had to rebuild all our separate application modules into a complete and integrated E-Business Suite. And we had to rebuild them on top of a single global database.”

  Critically, Ron Wohl and Mark Barrenechea quickly saw that working independently of each other, one concentrating on back-office functions and the other working on the new customer relationship software with which Oracle was going to take on Siebel, made no sense. Barrenechea says, “We’d use the same data schema, the same application program interfaces, and the same standards. That’s what became known as the E-Business Suite.”

  Not only did Ellison insist that development break out of its silos of specialization, he also demanded that development and Gary Roberts’s IT organization become, in effect, a single entity. The development group became intimately involved in defining and understanding the business processes that were to be implemented at Oracle and taking the final responsibility for deploying the software and validating its operational use. Roberts says, “We took all the application support people who used to be part of internal IT and moved them into the development groups. Today, we have what we call the three-legged stool for development. There’s me, Ron, and Mark. When those two develop a product, they hand it to me to impleme
nt. I also do final quality control against our entire employee base. What better way is there to see whether a product is reliable, can scale and perform to expectations?” The ratio of support staff to employee at Oracle has fallen from about 1 to 25 to as little as 1 to 75.2

  Roberts admits that at first there was a certain amount of suspicion on both sides: “It wasn’t exactly confrontational, but it was strained. The attitude was ‘You guys just run data centers, what do you know about developing products?’ But we were able to sit down with some of Oracle’s technical gurus, and they said they would have made exactly the same recommendations as us. So that legitimized our position, and from that time on it’s been transformed into a collaborative effort.”

  As well as forcing IT and development to work together as one, Ellison began the process of globalizing Oracle with IT. He decided to move all the IT people from their country and regional headquarters to a new global organization headed by Roberts. Not surprisingly, Ellison encountered fierce resistance from the feudal barons. The idea of relying on the corporate center for their mission-critical systems was anathema to them.

  Rather than just mandating the change (and then waiting for the shifting of blame every time a country manager missed a quota), the way around their resistance was a crafty mix of financial incentives and proof points that the new systems would actually work. First, the decision was made to provide the new global IT systems for “free” rather than as an allocated cost. Ellison wanted to establish the principle that managers should have to absorb only costs that they were directly responsible for incurring. Country managers who wanted to keep their IT in-house could do so, but it would be at the expense of both their operating margins and their bonuses.