Ellison argues that while Internet computing architecture will not change, its technology components will continuously get better and better. Networks will get faster, high-speed wireless networks will be ubiquitous, processing power will multiply according to Moore’s Law for years to come, displays will become more beautiful and user interfaces more intuitive. But the way the pieces are assembled architecturally, the fundamental structure of the Internet model—massive global databases, applications running on megaservers, applications and information accessed through a simple browser—that model won’t ever change. He says, “The old PC-centric client/server architecture was the equivalent of everyone having their own well for water, Honda generator for electric power, and VHF two-way radio for communication. The client/server model distributed complexity, required huge amounts of labor, and precluded economies of scale. For these reasons, PC-centric client/server computing became an evolutionary dead end.”
In this vision, the PC becomes just one of any number of network access devices—an appliance that connects to the Internet just as a television connects to broadcast signals, a telephone to the telephone network, or a light to the electricity grid. As with those networks, the user does not have to know anything about what it takes to get a television program, a phone call, or a sophisticated financial application to him. As with those networks, the technological complexity is hidden from view and managed by professionals. Nobody who points a mouse at a hypertext link has to know anything about the incredibly sophisticated computing and communications technologies—the programming languages, the transport protocols, the power routers, the massive servers and almost infinitely scalable databases—that have come together to deliver the application that’s just been chosen.
The story of Ellison’s struggle to make Oracle the first big software company to get to the Internet is for another chapter. But the philosophy of computing that triggered Ellison’s outburst against the PC and the subsequent long and, at times, bloody campaign to end the dominion of client/server is precisely the same as the one that has led him to his current battles with best-of-breed software vendors and powerful system integrators—namely, that the cardinal sin of the computing industry is the creation of complexity: a complexity that invariably results in information systems that don’t deliver timely and useful information because they use software architectures that result in chronic fragmentation of data.
Although Oracle first became active in the business applications market in the late 1980s, Ellison’s own involvement in their development was, at best, sporadic until well after his Internet epiphany. But when, in early 1998, he was pushed into taking a more active role, a number of things soon struck him as odd. The first was that there was no consistent view of Oracle’s applications among its customers. Whereas by this time just about all Oracle’s database customers were getting a product that either met or exceeded their expectations, the same was not true of the people who were buying its applications.
Ellison says, “Some customers loved our applications, some didn’t. That seemed very odd to me. How could customers react so differently to the ‘same’ product? My question revealed my fundamental misunderstanding of our applications business. Every applications customer didn’t use the ‘same’ product. The applications business was not like our database business. We finish our database software, and then you use it. But with our applications software, the customer, usually assisted by a team of consultants, makes major changes to our software before it’s used. Sometimes the changes work, sometimes not. No wonder customer satisfaction varied so widely. The business model of the customer ‘finishing’ our software for us seemed flawed to me. But that’s the way Oracle’s applications business worked, that’s the way SAP’s applications business worked, in fact, that’s how the entire enterprise applications software industry worked.”
What Ellison meant by the software not being finished was Oracle did not sell a complete range of applications. The chances were that anyone buying, say, Oracle’s financial and manufacturing software would need to add the products of perhaps three or four other companies to get the computer system they needed, and the job of knitting these different programs together that had never been designed to work with each other was the job of either their own IT people or highly paid consultants. Ellison says, “The applications software industry sold components, not complete business systems. The customer bought the components and assembled them into systems as best they could—no instructions included. No other technology industry in the world works this way. I mean, every Boeing 747 has the same basic components: fuselage, wings, and tail. You don’t buy a 747 and decide to speed it up by sweeping the wings back a little more. That would be expensive and dangerous. Who in their right mind travels in a heavily customized, one-of-a-kind 747? Why do people use heavily customized, one-of-a-kind business systems? Because they had no other choice. We wanted to give customers a choice of a complete and integrated suite of business applications.”
If the lack of completeness was one reason why customers modified application software from Oracle and other application vendors, another was that it had become traditional to do so. As Mark Barrenechea, the Oracle executive responsible for the CRM half of the E-Business Suite, puts it, “When most of us buy a car, we select a standard design and then choose from a standard set of options. Think for a moment about what that has meant for the evolution of the automobile: every brand has been able to incorporate every major advance in design because the factories have not been busy reworking every unit to the customer’s preconceptions about how, say, the transmission should work. But the convention with software has been for companies to buy standard products and then pay somebody to change those products so that they conform to the company’s peculiar business processes. And who is that somebody? Either an employee, who’s probably familiar with those processes but not with the software, or a consultant, who’s probably familiar with the software product but not with the company’s business processes.”
It was the usual problem with the computer business: a deeply ingrained preference for creating the maximum complexity for customers whenever possible and customers who were often their own worst enemies. Ellison became convinced that the peculiar characteristics of the enterprise application industry—the need to glue together a kit of parts purchased from multiple vendors and the urge to customize still further in an effort to make the software fit the way customer companies did business—were responsible not just for the frequently expressed dissatisfaction with Oracle’s own application software but for a general and widespread conviction that long and costly ERP and CRM implementations often failed to deliver the expected return on very large investments.
For Ellison, as always, the most pernicious consequence of unnecessary complexity was the resulting fragmentation of data. In the era of client/server computing, companies with global operations could not escape the problems caused by having to maintain multiple databases. But as Mark Barrenechea points out, it was, at best, a necessary evil: “Multiple databases mean duplication of data, conflicting data, inconsistent data formats, and multiplication of effort whenever data needed updating. Multiple databases also mean multiple data centers and multiple IT staffs.” However, the advent of Internet computing meant, at least in theory, that it was now possible for any company, however big and complicated, to move toward having just one central database with reconciled and integrated business data that could be accessed from anywhere in the world. But that wasn’t happening.
Ellison says, “The World Wide Web is a single unified network—all users who are connected can communicate with each other. We would never connect our users to separate networks that couldn’t communicate with each other. That would be nuts. However, we think nothing of having a marketing system from E.piphany with a separate marketing database, a sales systems from Siebel with a separate sales database, a customer service system from Clarify with a separate customer service database, a Web store from BroadVisi
on with a separate store database, an accounting system from SAP with a separate accounting database, and so on. It’s incredibly difficult and expensive to make these systems communicate at all—and it’s impossible to make them communicate well.”
In Ellison’s mind, this was the inevitable result of buying “best-of-breed” software, or, as he preferred to put it, buying pieces of kit. Even though the Internet was making it possible to consolidate data all in one place, best of breed, in which every application from every vendor ran on its own little database, was conspiring to undermine it. Supposedly there to fix the problem were the systems integrators from the likes of IBM and Accenture, who would write the custom programs that were needed to move, say, customer information from one database to another. Skillful consultants may be able to overcome some of the problems. But there are others that can never be fully resolved. Software from different vendors will have different semantics—even something as simple as defining what a “customer” is may differ—different underlying data schemas, which have to be coordinated but will scarcely ever be fully reconciled, and different user interfaces with conflicting design conventions and display elements. Even if the consultants have a proven integration method to link two pieces of software, APIs (application program interfaces) still have to be specially constructed to pass messages among distinct database schemas, limiting the amount of information that can be extracted as well as duplicating storage requirements.
The Internet should have made it possible for multinational corporations around the globe to exchange large amounts of information quickly and easily, but in practice, because every system was different and each one used multiple databases to store and manage information, that remained impossible. Most multinational companies found themselves with systems that couldn’t talk to one another. The Internet might make access global, but without global systems, that was of limited value.
Making all this complexity even worse was the fact that different and often competing software firms had no interest in coordinating their releases. When one of the software vendors whose products a company was using announced an improved version of the application, putting it in would involve upgrading the entire integration backbone and rewriting all those custom interfaces, not just for one system in one country but for different systems all over the world. The expense and trouble often meant that customers elected to reject new features that could be of real, albeit marginal, benefit to their business. The fact that every computer system was more or less unique meant that it was either frozen in time or required almost constant attention from teams of ever-helpful consultants to keep it up to date. No wonder Ellison described systems integration as “the gift that keeps on giving” or that in May 2000, IBM’s then CEO, Lou Gerstner, was able to boast at analysts’ day that for every dollar spent on software licenses up to seven were spent on services.
Ellison’s analysis was informed by what he’d encountered at Oracle. Although Oracle was using only its own applications, before the advent of the E-Business Suite, they were scarcely more integrated than many best-of-breed systems. Whenever Ellison meets customers, he describes what it was like: “Here I was, running the company that provides most of the world’s information management software, and our internal applications systems couldn’t provide answers to the most basic business questions. Like: How many people work at Oracle today? I didn’t know. Why? Well, the French had their own HR [human resources] system and database, the Germans had their own HR system and database, so did the Japanese and the Americans, and the Canadians, etc. In total, we had seventy separate HR systems. To find out how many people worked at Oracle worldwide, I’d have to inquire into all seventy HR systems. All our business data was fragmented into so many separate databases, it was difficult to get answers to many seemingly simple questions. How much did we sell yesterday? Sorry. Our sales order data was fragmented across a hundred and thirty separate accounting databases—one per country in which we did business. How many new customers did we get last month? Simply impossible to answer. Our customer data was fragmented into four hundred separate customer databases. Worse still, it was just about impossible to combine the customer data into a data warehouse because the customer data was not consistent across all those separate operational databases. For example, the same customer, Michelin, would have one customer ID number in the French database and a different customer ID number in the German database. In the data warehouse one customer, Michelin, thus looked like several separate customers.
“No wonder people have a hard time getting information out of their business systems. The current state of the art is inconsistent information fragmented across lots of little databases. And integrating and maintaining all these separate little systems costs much more than a single unified set of applications running on a single global database. So businesses are paying extra not to be able to get answers to their questions. But it’s worse than that. If your systems can’t easily share information, then the people within your company can’t communicate effectively. If they can’t communicate, they can’t cooperate. This results in a lot of friction between groups. Marketing doesn’t cooperate very well with sales. France doesn’t cooperate very well with Germany. Sound familiar? What was unbelievably frustrating was the fact that we were paying top dollar to maintain this mess—all these separate systems with their fragmented, inconsistent data. We had a huge IT staff running hundreds of loosely connected systems. We wanted one unified system with one global database. With all our information in one place, we could easily access and share information. We’d make better decisions, groups would cooperate, and IT costs would go down. All that would happen, but first we’d have to build a global applications system. That’s why we built the E-Business Suite.”
The high cost of implementing and running these systems, the fragmentation of data that resulted in very little useful information being available in real time—Ellison described them as billion-dollar clerical automation systems—and the near impossibility of being able to take advantage of upgrades gracefully were not the only things that customers were unhappy about. One obvious one was the vendors’ refusal to take responsibility for the failure of their software to deliver once it was integrated with the third-party applications that it had never been designed to work with. Consultants would blame the software firms for bugs in their products, and the software firms would blame the consultants for changing the code of their products to meet the requirements of individual customers. The customer was left standing miserably in the middle, paying huge bills and saddled with “shelfware” that had proved too difficult to install.3
A new and emerging problem was that the “e-business transformation” that the Internet was supposed to have made possible and that all the technology companies were hyping for all they were worth was far more demanding than the ERP era in which automation tended to take place inside a company within tightly defined functional silos. E-business not only demanded extending the enterprise to its business partners and customers, it also required highly choreographed interactions among all parts of the business. A significant point of e-business was to save time and money by exponentially accelerating the velocity of transactions. Ellison believed that best-of-breed software solutions, in which every application had to sit on its own database and information had to be moved laboriously and usually in incomplete form from one database to another through a custom-designed integration layer, would always struggle to achieve the seamlessness and speed implicit in the e-business promise.
The answer to the problems that enterprise application customers were facing, Ellison concluded, lay in doing two things, which he calculated that Oracle alone was capable of. The first was for all of Oracle’s applications to be tightly integrated both with one another and with the database through an architecture based on a single shared-data model. The second was to produce the first-ever complete suite of applications that would be capable of automating every aspect of a company’s business, from the traditi
onal ERP or back-office tasks, such as financials, manufacturing and HR, to the fancy new stuff that included customer relationship management (sales, marketing, and customer support), the supply chain, procurement, and Web stores. Ellison calculated that Oracle’s advantage lay both in its genes as a database company and in the sheer size of its development teams.
The starting point was to see the database as the hub and the applications as the spokes. Ellison says, “We had been thinking about the problem upside down, and as a result we were building the wrong software. We had been building process automation systems. We needed to build information systems—with the process automation layered on top. Traditional applications design focused on automating one particular process—like taking an order. Modern application design must focus on one piece of information—customer orders—and then layer on all processes that touch the order information: taking the order, billing the customer, initiating customer service, marketing additional services to that customer, and so on. It’s not the process at the center, it’s the data. It’s the ‘information age.’ If you’re building a marketing system, the marketing application should use the same exact customer information as your sales system, as your accounting system, as your customer service system. That way, every time you interact with a customer, it changes the same central customer database. All your customer information is in one place. All your product information’s in one place. All your applications share the same data. If you draw a picture of Oracle’s application architecture, the database is at the center and the applications are attached around the periphery. This is a radically different view of the world. If you draw a picture of Siebel’s CRM ‘suite’—they have a bunch of separate applications each with its own separate database—it looks like a charm bracelet. But there’s no charm in lots of separate databases. A single global database connected to a single global network—the Internet—is the ideal architecture.”
Softwar Page 7