"Is Oracle Technology Too Darned Expensive?" - Some Thoughts

An interesting article, "Is Oracle Technology Too Darned Expensive?", popped up this morning on SearchOracle.com. I tried, I really did, to leave this particular article alone...but the pressure kept building and my gasket finally broke. I just can't let the article pass. It hits on subjects too near and dear to my heart, especially the portion of the article that casts Oracle Support in a "less than flattering" light.

The article focuses on four major points:

1) "Nearly half of all Oracle customers will at least consider lower-cost alternatives to Oracle technology this year -- and the main reason they cite for doing so is Oracle's high prices, a new survey finds."

2) Support: Do You Get What You Pay For?

3) Buy in bulk to get deep discounts

4) At least Oracle's price list is easily accessible

Let's take another look at these points, one at a time in the order presented...

"Nearly half of all Oracle customers will at least consider lower-cost alternatives to Oracle technology this year -- and the main reason they cite for doing so is Oracle's high prices, a new survey finds."

On the surface of it, I can't disagree with this point. We do the same thing in my shop every year. In fact, we're going through the exercise right now. And, in doing so, we continue to reach the same conclusion: although the price is higher, so is the value.

One example of Oracle's higher value is in the area of scalability: we can't live with degradation in performance as we add more users and transaction volume to our enterprise applications. DB2 and SQL Server just don't scale up as well as Oracle.

The idea here is that simply focusing on price is very misleading. While a Kia may be have a lower price than a Lexus, the additional value of the Lexus (reliability, resale value, and even creature comforts) merit consideration in evaluating which car offers the best value. I suspect that, while nearly half of all Oracle customers may consider lower-cost alternatives this year, the number of Oracle customers switching to those alternatives will constitute a substantially smaller number than half. That's because Oracle technology represents a better value.

"Support: Do You Get What You Pay For?"

This is the part that really broke my gasket! I think some of us do get what we pay for. I also think that the same opportunity exists for all Oracle customers, so long as our expectations are realistic.

I own a Toyota Tundra truck - 4 years old, 52,000 miles, looks and runs like the day I drove it off the lot. My truck is in great shape because I take ultimate responsibility for the maintenance of it. Yes, my mechanic does much of the work. But it's my job to manage the maintenance and repair of my truck. I get what I pay for from my mechanic. My relationship with Oracle Support works in the same way.

I’m looking for help from Oracle Support in fixing my Oracle technology issues, but I do understand that ultimately it is my responsibility to manage my issues to resolution. I like to approach Oracle Support through a concept I recently learned called "Save Yourself".

A few years ago, one of my sons and I spent a weekend whitewater rafting on the Kern River. As our guide prepared us for the trip, he introduced us to the concept of "Save Yourself". The idea here is that each rafter's journey down the river will be somewhat unique. In addition, each rafter brings different levels of skill in rafting, swimming, and navigation. The guide would help us avoid the known trouble spots and would do his best to help us in bad situations (i.e., a capsized raft or a rafter overboard). However, the ultimate responsibility for saving ourselves would rest with each of us. My son and I found this out the hard way when our raft capsized and we each had to save ourselves, using a combination of what the guide had taught us a few minutes before (swim downstream at an angle that gets you to the raft or to shore - my son and the guide made the raft, I made it to shore) and the swimming skills we had developed long before this whitewater trip. Oracle Support works in much the same manner as my whitewater rafting trip.

Much like each rafter's journey down the river, each customer's implementation of Oracle technology will be somewhat unique. The uniqueness may come from hardware or software configurations, business processes, business intelligence and reporting needs, some combination of these, or from something else altogether. Whatever the source, you can rest assured that each customer's implementation of Oracle technology will be unique in some manner. So if we accept the premise that each implementation of Oracle technology is somewhat unique, it's probably also fair to say that Oracle Support cannot track each unique nuance from each of the thousands of customers using Oracle technology. If that's true, then the first step in applying the concept of "Save Yourself" to the arena of Oracle Support is to for each customer to understand their specific implementation of Oracle technology and the impact that their unique implementation may have on the functioning of that technology.

In much the same way that each rafter has a different level of skill, each customer has different sets and levels of skills available. Let me be clear on this point: the more you understand Oracle technology, the more satisfied you'll be with Oracle technology. This is not MS Office: run the install disc, register the software online, fire up Excel and get to work. Oracle technology is pretty complex stuff with lots of moving parts to meet pretty complex needs. Using Oracle products requires an investment in skills, either by purchasing the skills through new hires or consultants, or by investing in training to develop skills in-house. I continue to be flabbergasted by the number of users who don’t even read Oracle’s “Concepts” manuals before they begin using the products. If you go whitewater rafting without knowing how to swim, odds are pretty good that you'll eventually drown. Ditto for Oracle technology: to successfully utilize it, you need some basic skills for working with it. So step two in "Save Yourself" consists of possessing the skills necessary skills to work with Oracle technology (or at least develop a basic understanding of the Oracle technology you're utilizing).

Finally, there is a process to supporting Oracle technology. It’s very tough to gain much value from Oracle Support if you don’t understand how the support process works. When I hear or read stories about customers frustrated with the level of service received from Oracle Support, I typically start by asking a few questions (I’ve included references to more info via Metalink Doc IDs – Metalink login required - where appropriate):

1) Did you research your issue on Metalink (Metalink Doc ID 418297.1)?

2) What did the Configuration Support Manager (Metalink Doc ID 418277.1), Remote Diagnostics Agent (Metalink Doc ID 419359.1) or (for E-Business Customers) Support Diagnostics (Metalink Doc ID 418300.1) tell you about your issue?

3) What severity rating did your SR start with? What severity rating does it have now?

4) Has anybody on your team taken the Oracle Advisor Webcast "Working Effectively With Support?" (Metalink Doc ID 418294.1)

5) Where did you leave off in the Oracle Diagnostics Methodology? (Metalink Doc ID 312789.1)

6) Did you attempt to escalate the Service Request and, if you did, were you successful in doing so? (Metalink Doc ID 199389.1)

7) If you did escalate, did you consider engaging an Oracle Support Duty Manager?

I’ll usually find a problem to “zero in on” just by the answers I receive to these simple, process-oriented questions. Much like successfully navigating a river in whitewater rafting requires a guide with knowledge of the river, understanding how to work through the Oracle support process requires learning from a knowledgeable guide. I learned about the process of supporting Oracle technology from a great “river guide” within the Oracle Support organization. There are similar guides from Oracle Support waiting to teach you about the process of supporting Oracle technology through free Metalink Advisor Webcasts (Metalink Doc ID 405149.1) and user conference sessions (such as the Oracle Support sessions at the recently-concluded Collaborate 07). So the third step in the “Save Yourself” approach is to understand the Oracle Support process.

Black & Decker takes steps to reduce the probability that you’ll cut off a finger with one of their power saws. However, they can’t eliminate the possibility that you’ll hurt yourself if you’re not knowledgeable about the safe operation of power saws. Oracle Support is in a similar situation: they can take steps to reduce the probability that you’ll encounter an issue related to Oracle technology, but you do need to be: 1) knowledgeable about your implementation and use of Oracle technology, 2) possess some basic skills relating to Oracle technology, and 3) understand how to leverage the Oracle support process. The final responsibility to “Save Yourself” is yours. I get what I pay for from Oracle Support. How about you?

Buy In Bulk To Get Deep Discounts

Didn’t we learn about this in Econ 101? Buy in bulk and you’ll get a better unit price. It works for widgets, clothes, tires and just about anything else you can buy. Makes sense that it would work for software too. It certainly holds true with Oracle…my shop has bought in bulk to get very deep discounts on Oracle products. Enough said.

At Least Oracle's Price List Is Easily Accessible

It’s true. You can get it here.

So, as you have probably figured out by now, I do have a few issues with the negative tone of the SearchOracle article. My perspective is that, although it is expensive, Oracle technology also renders high value in return for the cost of my investment. I represent a large customer and, frankly, we have yet to find a better deal...

New Blog - Yak About Apps

I recently had the opportunity to become friends with Linda Fishman-Hoyle, who is a Sr. Director for Oracle's Cross Applications Product Marketing team. Among other things, Linda is Editor-In-Chief of the AppCast podcast series.

Linda has recently started a blog, Yak About Apps , intended to share the latest news on Oracle Applications. Knowning Linda, I suspect she'll mix in a good portion of fun as well as some good info on Oracle Apps. You'll want this one on your short list...

I Can See Clearly Now

I've spent some time recently attempting to develop a clear vision of Fusion Applications. It's a lot like piecing together a puzzle; although Oracle really has not come right out and described Fusion Applications in specific terms, there are numerous clues from different sources that fit together to provide an overall picture. Although the usual caveats apply, here is what I think I know:

• The whole concept of Fusion, including Fusion Middleware and Fusion Applications, is an evolutionary journey rather than a set of specific product releases. Think iterative and incremental releases rather than single, "big bang" releases. And an iterative approach is a great thing for Oracle customers.
  

• Fusion Applications will be more more process-centric than any of the Oracle Application suites we know today. The frame of reference, rather than a suite of applications like Purchasing, will be collections of end-to-end business processes like Procure-To-Pay grouped into lifecycle buckets like Financial Management.

• Most of the business processes will be pretty horizontal (i.e., industry generic) at first, with industry-specific vertical processes appearing as Fusion Applications continue to evolve.
  

• Not all customers will need to move to Fusion Applications right away. For those customers who have generally good fits out of the box between their business processes and their current applications product line, there won't be much incentive to move. These customers will get the greatest benefits from the Applications Unlimited commitment.
  

• I'm very happy about the flexibility provided by the Applications Unlimited commitment but, because I do believe in the Law of Diminishing Returns, I doubt the commitment will last forever. Sooner or later, all Oracle customers (whether they are apps customers or not) will probably wind up on some type of Fusion technology stack.
  

• For those customers moving to Fusion Applications, the best way to get going (in simple terms) is to eliminate as many customizations as possible, plan the migration of those customizations that simply cannot be eliminated, consolidate data (mainly to support the business intelligence functionality in Fusion Applications), and begin using Fusion technology components (such as BI Publisher aka XML Publisher) today.
  

• A pretty good preview of Fusion Applications is appearing in the form of the Applications Integration Architecture. The Applications Integration Architecture may eventually be very close to the first release of Fusion Applications, with the user interface and the unified implementation of business processes being the biggest differentiators between the two products.
  

• Although I may be stating the obvious, I'll so so just to clear up any misconceptions. Customers will not need to move to Fusion Applications in order to utilize the Applications Integration Architecture. However, customers who do move to Fusion Applications will still be able to leverage the Applications Integration Architecture. It's not an "either or" choice.
  

• I suspect that Fusion Applications, the Applications Integration Architecture, the E-Business Suite, PeopleSoft, JD Edwards, Retek, and the rest of the Oracle Applications product stable will all eventually incorporate the standardization of Enterprise Business Objects.
  

• The greatest challenge to Oracle customers over the next few years will be to develop an understanding of the various choices Oracle has made available, so that each customer can make intelligent decisions about those choices based on the specific needs of their enterprise.
  

Yup, in the words of Johnny Nash, "I Can See Clearly Now"...or at least a little better than I could before.