One of the most common risk gaps during the lifecycle of Oracle at the enterprise is a lack of alignment. Legacy systems or architectural systems may cost extra in support year after year, but a simple change to the architecture may reduce your support costs. To give you an example, if you have older servers with single core processors and you move to a multi-core environment, you can usually save significant money in your licensing and your annual support costs. Let’s assume a server that had four single-core processors on it licensed singularly, roughly $47,500 for a single CPU license that would be $190,000 ($47,500 X 4 processors). Add 3-years of annual support for another $125,400. So, roughly, your cost of ownership would be $315,400. If on the other hand, you had employed a multi-core environment and used Intel CPUs, there is a factor that is applied in the Oracle licensing which is one-half, so you only need to buy half the licenses for the total number of cores that you have. For the same number of cores, you would be paying exactly half as much. In a three year period, you would save roughly $157,700 which may very well justify going to a different architecture.
Auto renewal on your maintenance and support agreements need to be closely monitored. It is better that you leave the auto-renewal alone, so that you are in a better position to renegotiate each year. It’s at this point that the lack of a central repository or tracking mechanism may become really obvious because without knowing throughout the year when the renewals are coming in, it becomes difficult to budget and it can get you into trouble. It’s important to note that within agreements of Oracle, support renewals may contain their own Terms and Conditions which may alter some of the Terms and Conditions that you fought so hard to negotiate within the original ordering document. It’s really important that you factor in these support renewals and the support costs during the procurement process and scrutinize those during the support renewals. You could end up thinking that this is just a purchasing exercise of support renewal year to year when you actually may be devaluing that big investment you made.
We recently answered that question in SearchOracle.com, where Miro is part of the Ask the Oracle Expert: Questions & Answers column. Here’s the original question and our answer.
Has Oracle changed its policy in licensing databases on VMware? From my understanding, they are treating VMware as soft partitioning. Is there any official documentation with regards to VMware/Oracle licensing that I can refer to?
Yes, in a nutshell it is treated like soft partitioning given that they are not recognizing VMware for purposes of limiting CPUs needing licensing. No, there is NO official Oracle document regarding Oracle’s treatment of VMware, likely because they are still developing their position on the topic.
While some information on Oracle’s acquisition of Sun has been made public, there are still a number of unanswered questions - one of them being about licensing. While we don’t have any more information on this, but we’re speculating that it can be a very sweet deal for the right company.
Retailers are a unique breed when it comes to licensing. We recently worked with a number of retailers seeking to understand their Oracle licensing and they all had a mix of Named User Plus licensing and CPU licensing. With Oracle or any enterprise software for that matter, licensing is about access and authority, but not necessarily limited to people. The latter being an extremely important point to software licensing, usage and retailers.
One of the major differences in the retail industry is the equipment that houses the software application - from point of sales equipment such as registers and scanners to backroom inventory systems. These systems need to be considered as part of the licensing mix and, more often than not (in our experience), the IT executives at retailers overlook them.
So, if you’re a retailer, you may want to take another look at your Oracle licensing inventory.
Today, mergers and acquisitions are as common as marriages or people setting up households together, and may present unfounded opportunities for lowering your Oracle support stream and uncovering more favorable terms and conditions.
Reinstating terminated support. When a company takes on an acquisition or makes a divestiture, the hard assets - furniture, equipment, electronics, etc. - are easily categorized or sold off, but it’s easy to overlook “soft” assets such as software, licensing and support. In both scenarios (M&A or divestiture), you likely have access and/or rights to reinstate a more favorable prior support stream, creating a more advantageous environment including pricing. Please note: Terminated licenses cannot be reinstated as we accidentally and incorrectly mentioned in this morning’s newsletter.
Don’t forget about support renewals. Many of your older software vendor contracts probably have some sweet Terms & Conditions that you don’t want to lose. Remember that you are responsible for the annual support renewals (and not your Oracle rep). Every time you allow a renewal to lapse, you lose those advantageous T&Cs and licensing goes up between 15 to 25%.
Get it in writing. Get all assumptions clarified and then confirmed in writing. You don’t want to assume anything and any discussion or email in which you are getting the best leverage should be mentioned in detail within your agreement. We see a lot of our clients - even the largest Oracle enterprise - treat emails and verbal discussions as legally binding agreements, which is untrue in the case of an Oracle software licensing agreement. It is not up to the sales person to remember what he/she promised you or what concessions were discussed and agreed upon. It is up to you to remember and make it legally binding.
Confirm assumptions with examples. For example, your SLA may state that you have worldwide usage rights. You assume that you can use your Oracle product anytime, anywhere. However, that would very likely be an incorrect assumption. You should inquire whether the worldwide usage rights are affected by:
where the users reside
where the software resides
location of servers
client location and usage
We often drill down to these small, but extremely important, details during the discussions we have with Oracle on behalf of our clients. When you clarify all the assumptions, the last step is to ensure that there is language within your SLA that defines usage more clearly.
Never assume a License Usage Right. If you think that your Oracle license allows you specific actions or specific functions, you need to check your SLA. For example, if you have eBusiness Suite and you assumed that the collection module was included in the accounts receivable functionality (which is reasonable). The collections module is actually a separate module and a separate cost.
Never assume that the vendor doesn’t know. We have many companies come to us for the first time and they tell us about a yet-to-be disclosed data warehouse launch, a merger or company acquisition, layoffs, or other major corporate changes. Often, the company believes that Oracle doesn’t know about it and they want to know what their SLA options are. However, don’t be too sure of that. With larger companies, it’s not too hard to find information about the organization including the inner workings and operations.
We get a lot of questions about Oracle’s processor core factors. Core factors can change and this is particularly difficult when you’re the person in charge of tracking changes in licensing or the procurement process. Case and point, the Sun UltraSPARC T2+ core processor licensing changed from 0.75 to 0.50. As soon as the change is in effect, your organization is considered out of compliance.
See Oracle Processor Core Factor Table, which charts vendor and core processor licensing factors. Changes can be found as a footnote at the bottom of the page.
One of the most common risk gaps during the lifecycle of Oracle at the enterprise is a lack of alignment. Legacy systems or architectural systems may cost extra in support year after year, but a simple change to the architecture may reduce your support costs. To give you an example, if you have older servers with single core processors and you move to a multi-core environment, you can usually save significant money in your licensing and your annual support costs. Let’s assume a server that had four single-core processors on it licensed singularly, roughly $47,500 for a single CPU license that would be $190,000 ($47,500 X 4 processors). Add 3-years of annual support for another $125,400. So, roughly, your cost of ownership would be $315,400. If on the other hand, you had employed a multi-core environment and used Intel CPUs, there is a factor that is applied in the Oracle licensing which is one-half, so you only need to buy half the licenses for the total number of cores that you have. For the same number of cores, you would be paying exactly half as much. In a three year period, you would save roughly $157,700 which may very well justify going to a different architecture. 
