The Ugly Truth About Oracle

by | Aug 9, 2001

Last week, an article in the Wall Street Journal reported that Oracle had overstated the number of customers that it had for its most recent release (release 11i) of its applications. The article also implied that customers were not buying 11i or were not migrating from older versions of Oracle’s applications suite because the release […]

Last week, an article in the Wall Street Journal reported that Oracle had overstated the number of customers that it had for its most recent release (release 11i) of its applications.

The article also implied that customers were not buying 11i or were not migrating from older versions of Oracle’s applications suite because the release was full of bugs.

Oracle has some problems to be sure — and I will discuss them in a few minutes — but the author of the Wall Street journal was misinformed on several fronts. Here’s the real story.

First, 11i has been available long enough that it has been patched many times to fix bugs, so “bugs” should not be impacting sales or decisions of existing customers to migrate. I seriously doubt that this is an issue.

In fact, a new customer would have to be crazy not to implement release 11i for a number of reasons:

  • Its user interface is vastly improved from prior releases. It seems that in 11i, Oracle suddenly discovered that you could put tabs on windows rather than require users to proceed through a maze of screens to perform even the simplest task. The new user interface is more efficient and easier to use.
  • 11i uses a thin client architecture. This means that users do not need to soup up or replace their desktop machines to use the application. It also means that performance across a wide area network is also vastly improved.
  • The functionality is greatly improved over previous releases. For example, the sales order entry module — an area of critical importance — has been overhauled.
  • Oracle will eventually drop support for older releases — why implement a release that will no longer be supported?

But there is an ugly problem that Oracle faces, and they don’t want to talk about it.

Many of Oracle’s customers are large, multi-site, multi-national companies. Oracle is such a complex, convoluted product that these companies spend millions of dollars with consultants, and take years to get the product fully implemented in all of their sites.

The fact that it takes large, multi-site companies years to fully implement Oracle is one of the reasons why customers don’t migrate promptly to new releases. A company that is partially implemented on one release is not likely to consider migrating to a new release until the entire company has been fully implemented (if then!).

Furthermore, a company that has Oracle partially implemented is not likely to consider mixing versions of Oracle, that is, having different sites operating on different releases of the Oracle application. There are two reasons for this.

  1. One of the big benefits that large companies hope to achieve under Oracle is integration. Integrating all of the sites in one centralized database facilitates the ability for these sites to perform interplant demand planning and to perform financial consolidation. It also greatly reduces the amount of effort that might otherwise be required to create and maintain redundant data. For example, if the various sites are using some of the same suppliers and customers, having all of the sites in a single integrated database means that common suppliers and customers only have to be set up one time in the data base. If each site had its own independent installation of Oracle, users at each site would have to create and maintain separate master files, meaning that eight users in eight sites might be creating and maintaining redundant item, supplier, and customer records. You lose the benefits of integration if you have different divisions of the company operating independently on different versions of Oracle.
  2. For argument’s sake, let’s assume it is possible for a division of a large company to implement version 11i of Oracle even though the rest of the company is on an earlier version. This might be possible if the division is a different animal than the rest of the company, that is, a business that has little in common with the other divisions of the company. In such a case, there would be no need to implement interplant demand functionality, and there would be no penalty to pay from a data redundancy standpoint by putting this division on its own server on the newest version of Oracle. But there is a problem — a serious obstacle that prevents most companies from doing this. Most companies cannot afford the technology infrastructure — hardware and people — to support two different versions of Oracle concurrently. Oracle is as expensive to support and maintain as it is to implement.

Ironically, Oracle is a victim of its own strategy of designing the package to fit as broad a market as possible. Oracle has so much breadth and depth of functionality, and so much flexibility, that it is by nature a complex, convoluted package that is very difficult and costly to implement. Oracle customers spend as much time or more figuring out what features of the product not to use as they do figuring out how to use the features they really need!

A company, having gone through the effort, time, and expense of implementing Oracle one time, is likely to view Oracle as a legacy system (a system that will never be upgraded to a newer release) immediately upon the completion of implementation.

In fact, if I were the CEO of a major corporation, I would be willing to sacrifice some of Oracle’s functionality and flexibility for a simpler solution that would give me most of the functionality I need, but could be implemented at a fraction of the cost of Oracle in a fraction of the time. But IT directors are more likely to use their influence to go with Oracle for the same reason that companies used to go with IBM — it is perceived as the “safe” solution. Why take a chance doing business with a smaller company?

What does all of this mean to Oracle? It means that Oracle faces four serious problems going forward:

  • Existing customers will not migrate quickly to new releases, making it appear that the newest release is not gaining market acceptance for other fallacious reasons. Hence, yesterday’s article in the Wall Street Journal.
  • Oracle will have to continue to support older versions of its applications for many years longer than they would prefer to, meaning that Oracle’s administrative costs for support will increase over time.
  • If customers do not migrate to the newest release, Oracle will have difficulty selling old customers new products that are tied into the latest release, which could impact future revenue streams.
  • A company that chooses to view Oracle as a legacy application, with no plans to upgrade to a newer release, might eventually drop support. This could impact Oracle’s annual maintenance revenue streams.

The views expressed above represent those of the author and do not necessarily represent the views of the editors and publishers of Capitalism Magazine. Capitalism Magazine sometimes publishes articles we disagree with because we think the article provides information, or a contrasting point of view, that may be of value to our readers.

Have a comment?

Post your response in our Capitalism Community on X.

Related articles

No spam. Unsubscribe anytime.

Pin It on Pinterest