Continue reading »]]> This article about Itanium reminded me that the most strategic decision CIOs make regarding Oracle is where to run databases. Admittedly, my experience with Itanium years before Oracle announced desupport was consoling unhappy customers through support issues. Had Mark Hurd stayed at HP and IBM acquired Sun I suspect Oracle would have continued supporting Itanium for years to come. As the saying goes, a house divided cannot stand, and Oracle continues to rake in piles of cash from Oracle running on HP-UX.

The de facto strategy in the 2000s was to move from expensive UNIX gear to Linux on x86, including RAC in many cases. The 2010s offer a different dynamic for those that remained on UNIX through the 2000s. First, the software required to make a stack of x86 machines mimic UNIX-level quality is not only expensive, but also puts customers at the mercy of perpetual software agreements and ever-changing licensing metrics. Second, x86 is not as efficient as RISC chips and UNIX virtualization. I typically size x86 environments with at least twice the cores as IBM PowerVM, for example, which further exacerbates licensing fees. Finally, Oracle’s licensing policies for partitioning favor UNIX-based virtualization.

So where does that leave us? I typically recommend that customers study five scenarios from a financial and technical perspective:

• The existing deployment
• Exadata, i.e., Oracle’s preferred strategy for deploying on x86
• Any other non-RAC x86 platform such as Vblock, VMware on Dell, etc.
• A UNIX flavor such as Sun Solaris or IBM Power
• Any anti-Oracle solution, such as DB2 or SQL Server

Each scenario is sized, priced, discounted, etc., then stacked up against each other in pretty graphs that make the cost of ownership numbers unequivocally clear. I think this analysis is vital even if the thought of migrating to one of the scenarios is abhorrent. The push-back goes something like “we just finished moving everything to Linux and are never going back.” Then why not affirm the strategy by demonstrating it as the path to continue on? Many of those decisions were made in drastically different market conditions.

There are many other dynamics such as staff capabilities, consolidation, virtualization and migration strategies, and flexibility and economics of existing contracts, just to name a few. They all must be accounted for, quantified financially and included in platform comparisons. There is also the art of vendor management and negotiation. Oracle, for example, will vigorously defend an existing software support stream. Simply stated, uneducated and fractured customers can get eaten alive by big vendors. Many customers don’t understand a particularly nasty contract until many years later.

Having done this analysis for many customers, I have reached strong conclusions about how to do business with Oracle and what platform to run databases on. Happy to discuss it, too!

Continue reading »]]> I entered the Oracle food chain in 1996 and the database giant’s reputation wasn’t positive then: aggressive, inflexible and expensive. Not much has changed 16 years later. People still tell me that they’d have moved from Oracle years ago if not for the quality and necessity of Oracle’s core software products.

Articles such as this, however, suggest that something under the surface has changed, not for the better and it started when Oracle acquired Sun. While the traditional negativity towards Oracle has rarely resulted in anyone moving to a different database, handing an even larger portion of the IT estate to Oracle is unappealing. In other words, Oracle is struggling to convince its database customers to adopt its hardware.

Oracle’s high-profile litigiousness doesn’t help either. This article points out how egregious Oracle’s $6 billion damages claim against Google is. The win against SAP in late 2010 was deflated after a judge knocked the $1.3 billion win down to $272 million. Who knows where Oracle may point its legal team next, but it seems clear that winning corporate lawsuits is strategic to Oracle’s profit model.

There’s no shortage of positive press, of course. ORCL is steal at $27 $25.70, cloud will be a boon for Oracle, Fusion apps are progressing and SPARC T5 has the potential to be the de facto architecture for Oracle database clusters. That’s all good news and Oracle has the money to execute, but I recommend hiring a PR firm to help with curb appeal.

The difference after decades of database dominance is that Oracle actually has competitors, and those competitors aren’t as flamboyant, arrogant, channel conflicted and inflexible. With Oracle, things end up seeming so personal, and that’s akin to knowing the politics, religion and personal habits of your favorite movie star.

First, I’d like to see Oracle return to certifying on every operating system, including hypervisors and chipsets. Second, I mentioned here that Fusion apps is the most important strategy for Oracle to execute on, including engineered systems that have all the moving parts installed and running. Making databases run faster is easy compared to savings customers $zillions in implementation and migration fees. Finally, open up (even if ever so slightly) to the channel. Oracle’s competitors may not be benevolent, but they let resellers create margin on their products. These things may not improve Oracle’s image problems, but I think it will keep the anti-tipping point at bay, if not propel Oracle nicely into the future.

Continue reading »]]> Two common complaints about Oracle are how expensive it is and how inflexible the terms surrounding software support are. In some cases, after closer inspection, a customer realizes that it is actually getting a better deal on annual support than originally thought. The way to determine this is by reverse engineering the effective discount against list price. (Remember, support is typically 22% of net license fees.) As you may suspect, it is common that support payments are at a premium after years of increases. As a side note, Oracle seeks to block purchases designed to reduce existing support by re-licensing identical software at a deeper discount.

Things get interesting when no apparent connection can be made between annual support and current price list. This is common in the years following deals where antiquated metrics are traded in for modern ones. Bundling and un-bundling products, and revenue-based metrics can lead to this as well. It is possible in such cases for the resulting software support to be higher than 22% of list price. The closest metaphor I can make is to the housing market where homeowners now find themselves in an upside-down mortgage. What was originally paid is no longer applicable and list price is a frustrating comparison of apples to oranges.

The Occupy Wall Street movement is partially fueled by anger towards bailed out banks that won’t write down loans for home owners that are under water. Oracle’s customers are by no means unsuspecting citizens that have been duped by predatory lending, but many do find themselves in a spaghetti mess of indecipherable contracts that can’t seem to be terminated without triggering fee increases elsewhere. It should be noted that Oracle doesn’t like old complex contracts either; some customers have learned how to use this complexity to their advantage by holding on to hard-to-measure metrics such as Concurrent Device.

Oracle’s solution is to roll old CSIs into new deals thereby preserving and securing support revenues. Unlimited license agreements do this quite nicely. Customers, on the other hand, either don’t know their options or get pressured into unfavorable deals despite several rounds of legal and procurement review. The bottom line is that a detailed, informed understanding of your software entitlements is key to managing Oracle assets and getting the most value out of your annual support payments.

Continue reading »]]> I often feel like Debbie Downer when discussing Oracle licensing policies, especially with regards to server partitioning. The conversations typically involve what may seem to be a loop-hole, i.e., a means by which to forego licensing. Oracle seems to believe that it is abundantly clear on the matter. Meanwhile, the rest of us can produce technical nuances that do not exactly fit into an existing policy.

On that note, here is my tongue-in-cheek check list for whether a core must be licensed in the case that it is ever made available for Oracle to run on. So, if any of the following are true …

• You are asking whether a core must be licensed
• You are paying the server manufacturer for use of the core
• Oracle has a competitive offering for the purpose of the core
• Oracle can smell VMware anywhere on the property
• Oracle is unwilling to document a licensing policy in the order document or OLSA
• Your Oracle rep states a gracious interpretation of licensing policy
• You are still reading this post

… then licensing is likely required.

Finally, if it runs Java, then it will eventually require licensing. Not only just smart phones, but also microwaves, alarm clocks, Blu-ray players, GPS watches, pacemakers, levitating cars, space ships, etc.

Click here for part 1.