The Origin of The ULA
Jeff Keplar Newsletter April 13, 2024 11 min read
It's Thursday, and on the front page of the Wall Street Journal (WSJ), in the lower right corner, is an Oracle ad.
It might be "We Kick Ask" or "Fastest Ever Database Performance."
The Year is 2004.
The ad campaign employs a technique called comparative advertising.
This is unremarkable because Oracle Founder and CEO Larry Ellison prefers targeting his competitors, and Oracle's ads are a fixture in that location for every Thursday edition of the WSJ.
Within Oracle, it was understood that Mr. Ellison was interested in Oracle's ad content and marketing strategies.
Outside of Oracle, it was often discussed and sometimes written about.
Like "Mac vs PC" or "Pepsi vs Coke" Mr. Ellison preferred Oracle versus IBM, SAP, or Microsoft.
He also liked to take it to another level, making bold claims about Oracle's capabilities and highlighting a competitor's deficiencies.
In particular, IBM took offense to the ads, complaining to an advertising industry body and eventually the FTC that Oracle's claims were not based on evidence and contained misleading comparisons with IBM products.
No action was taken, and Mr. Ellison's influence on Oracle's marketing continued to be evident in the foreseeable future.
The Oracle Sales Organization
Often imitated but never replicated, Oracle had built a sales organization and developed a sales culture that was the envy of the tech industry.
It had plenty of company.
Cisco, EMC, SAP, and Sun Microsystems might all have a case for being the heir to IBM's 30-year run as the top field sales organization.
They all had one thing in common, which Oracle did not.
With Thomas Watson, John Chambers, Joe Tucci, Bill McDermott, and Scott McNealy, all of them had customer-facing sales executives as CEOs.
Yet Oracle stands out in the minds of most industry pundits, Wall Street executives, and Silicon Valley venture capitalists for the following reasons:
The longevity of its performance as a growth stock
The lack of a material differentiator in the capabilities of its primary product lines
The conceptual intangible nature of its products
The lack of a customer-facing Founder, CEO
The business practices it implemented and enforced to protect its IP.
Possibly because Mr. Ellison was famous for running the company with a top-down approach, and maybe due to his reputation with its marketing, many believed he exerted the same influence with Oracle's sales organization.
Nothing could be further from the truth.
In this week's edition of Win More, Make More, I share how Larry's genius empowered and enabled a small group of sales leaders to do what they do best.
At a Crossroads
The Internet was nearing its tenth birthday.
eCommerce was becoming a reality and beginning to transform the retail industry.
Supply chain optimization was hitting its stride.
Wireless networks had advanced to the point that landline replacement was inevitable.
Even the largest, most conservative companies were viewing change as inevitable.
Technology was the enabler.
Oracle was in an excellent position to capitalize.
Yet, the explosive growth it had experienced with the shift from mainframes to minicomputers, hierarchical file systems to relational databases, and accounting systems to ERP had taken its toll.
Its largest customers were furious with its business practices, especially the licensing policies.
Instead of having conversations with their account teams about how Oracle could help them embrace the new opportunities in front of them, their discussions were consumed by Oracle license administration.
The path they had taken with Oracle had invariably left them with a mixture of license metrics, old and new.
The situation likely worsened if they had made any acquisitions during the last ten years.
Examples (in chronological order):
Per User - entitles a nameless user
Concurrent User - only entitles the maximum number of users at a given moment; there was no practical way to enforce this for the customer or Oracle; Oracle had no meter on its software.
Named User - entitled a named user, preventing the sharing that took place with Per User
Enterprise License Agreement (ELA) - entitled an enterprise and was licensed by full-time employee, not by use.
CPU - entitled a server to be licensed to support uncountable populations like internet access and nonhuman devices; a CPU was essentially a microprocessor chip
Power Units - entitled a server to be licensed to support uncountable populations: created to solve when all CPUs were not equal in capability; used formulas in an attempt to normalize across disparate CPUs.
Customer Objections:
We don't want to pay a full license for a user who only uses the software twice a month.
All CPUs are not equal in compute capability.
We have to buy a license for our janitor?
We disagree with how you calculate a Power Unit.
Power Unit is an Oracle term that is not used by anyone else in the industry.
You've changed your licensing four times in the last five years.
We can't count.
You've made it impossible for us to remain within our license entitlements, so we will not invest any more of our resources in doing so.
Oracle's sales org was expected to deliver double the YoY annual growth for the industry.
Our customers were fed up.
What were we going to do?
Tony
Tony was our field sales leader for the Technology business (Matt had Applications.)
He was the role model for any sales leader who wanted to be the best in their field.
Very supportive of his team, Tony led from the front and was great with customers.
He was a problem-solver and did not shy away from difficult situations where the solution was not evident or easy.
I worked for Tony for ten of my nineteen years with Oracle.
During that time, Tony and I made sales calls in Denver, Boise, Seattle, Beaverton, San Antonio, Dallas, New York, and Atlanta.
I have stories for every one of them.
This one takes us to Atlanta.
Cingular Wireless
Greg, the long-time IT Finance person, had something on his mind, and he wanted to run it by me.
I had previously covered Cingular, but with the realignment in 2003, it was Donnie's account now.
Donnie's rep, Ken, used to work in my Teleco group, and informed him and Tony of my prior relationship with Greg and this new request.
Tony called, and I was happy to help.
We met in Atlanta and went to visit Greg.
Once we finished with the pleasantries, Greg got down to business.
"IBM was here last week."
"They proposed an Unlimited Agreement across all hardware, software, and services."
"We are considering it and thinking how something like that might work well for Oracle, too."
"It simplifies in several areas."
"They used historical data they had about our spend with them to price it."
"I don't suppose Oracle would ever consider something like that for us?"
We asked a few questions, attempting to learn as much as possible, and then asked Greg to let us noodle on it and get back to him.
On our way to the car, Tony and I looked at each other and said: "No way Oracle would ever go for it."
But then I heard: "Jeff, just think if we could pull this off, the problems it would solve."
Protect the Gold
Larry had organized the company to separate sales and business practices, with a common manager only at the CEO level.
Inside the global business practices org was a group called HQAPP, an acronym for Headquarters Approvals.
HQAPP was a small group of knowledgeable people who had been with Oracle for a significant period.
None of them trusted anyone in sales.
I believe those were their instructions from above and not due to personal experience.
To understand what we were dealing with, it is helpful to put into words a series of statements that this group could have very well spoken in one of their meetings:
Don't trust them
They will give Oracle's software away the minute you turn your back
They are not interested in the future of this company, only in their next commission check
All of their customers lie about their Oracle usage.
Harsh?
Maybe.
But now you have the picture, as unfair as it might be to those individuals.
Every nonstandard deal required approval from HQAPPs.
With the Fortune 500, every order was nonstandard.
I had worked with HQAPP quite a bit and was beginning to earn their trust, inch by inch.
The Plan
Tony asked me to give it my thoughts.
He would do the same, and we'd grab some time next week to review.
We agreed on a list of items that looked pretty close to this:
Unlimited deployment was a must, but it would scare the daylights out of HQAPP.
We should find a couple of ways to "limit" the Unlimited.
This license needed to grant entitlement to all usage -our customers had had enough of the annual surprises that their entitlements failed to contemplate.
This license needed to replace all their legacy licenses, so we needed a plan for license migrations.
We needed to make a list of reasons why our enterprise accounts would buy this license.
We needed to list why they would not buy this license.
We should run this idea past a few accounts to get real-life feedback.
We needed a sales strategy to sell this to HQAPP.
Why was this good for Oracle?
Where was there a risk to Oracle, and what were our plans to mitigate that risk?
I had five peers in Tony's org at that time, and he wisely chose to include all of them in this process.
Everyone contributed over the next few months, while Tony slowly began warming HQAPP up to the idea.
The Unlimited Deployment License
We landed on what we initially called the UDL:
Deploy as much software as you like for a fixed upfront license fee
Unlimited deployment occurs over a mutually agreed period
After this period, you tell us how much you have installed and running, and we grant you perpetual processor licenses for every Oracle product running on those computers
Your Annual Support Fees for the first year following the UDL are precisely the same as in each year of the UDL - no matter how much you deployed, your Annual Support does not change.
The "limitations" we placed on the "Unlimited"
Limited to a term, preferably three years
Limited to Oracle Technology (Database and Middleware)
Perpetual licenses granted upon certification had to be the Processor metric
No Hosting - The UDL and the Processor license were limited to supporting the customer's internal systems.
What's the Worst Thing That Could Happen?
The most challenging task in this story was selling the concept to Oracle, specifically HQAPP.
How did we convince Oracle to allow us to write orders granting the largest companies in the world unlimited deployment of Oracle technology for three full years?
How indeed.
Up to that point, HQAPP had worked with Product Management and a pricing committee to create all of Oracle's license metrics.
They invested countless hours of rigorous thought to protect Oracle's IP.
They ran scenarios to mitigate the risk of "selling out" a customer, preventing future revenues.
Oracle needed to be receiving commensurate value for the use of its software.
We knew we were inserting ourselves ("Sales") into the inner sanctum of Oracle.
A key success factor was already in place for us.
The person delivering this message had to have credibility within the walls of Oracle.
They had to have an impeccable reputation across product management, the executive committee, REVREC, and especially HQAPP.
We had Tony.
He was orchestrating our story and the approach.
Benefit #1
We began with customer satisfaction.
Our largest customers were at odds with Oracle's business practices.
The legacy license metrics made it too cumbersome to count and remain compliant.
This UDL eliminated that and we believed it would eliminate the agita.
Happy clients buy more.
Benefit #2
Next, we addressed pricing the UDL.
Each deal had to be one-off.
We acknowledged that this was not ideal at scale.
But, to obtain the most value while mitigating Oracle's risk, the methodology we created was a custom project for each account.
In addition to solving the license administration problem, the unlimited deployment grant had a value of its own to our customers.
Oracle should receive compensation for this value, meaning the UDL came with a premium compared to other licenses.
For example, a customer estimates they will deploy 1,000 Processors of the Oracle database over the next three years.
They could purchase licenses as needed, a couple hundred at a time.
Or, they could purchase all 1,000 up front, receiving a more considerable discount.
But if they only used 300 in the first year, they would have 700 sitting on the shelf, for which they would be paying Oracle annual support fees.
With a UDL, the price would be calculated based on a proforma of a staggered deployment of their 3-year estimated usage.
But unlike the other options, the customer could deploy 1,000 Processors (or more) in the first month of their 3-year term for a fee based on staggered purchases.
We felt that Oracle should receive some premium for this capability, whether it was used or not.
These first two points would earn our proposal some credibility.
In my opinion, the next two earned us the okay to take it to a few customers.
Opinion #1
Experience had taught us that customers frequently bought more than they used.
They wanted to lower their price point, so we pushed them to increase their commitment.
Bigger orders received more significant discounts, lowering price points.
When they bought more than they could use, this created shelfware.
Shelfware wasn't suitable for either party, but it happened even when we had not pushed for more.
IT projects are typically complex, containing many dependencies and unknowns.
Companies established goals and objectives in the executive suite and pushed them down into their LOBs for execution.
Many IT project timelines were overly ambitious to meet the goals set in the executive suite.
Much like when one goes to a nice restaurant and orders the 16-ounce New York Strip steak with all of the sides, it's human nature to bite off more than one can chew.
The "eyes are bigger than the stomach" phenomenon isn't confined to steakhouses.
It happens frequently in large enterprises.
We offered the opinion that it was more likely for a customer to overestimate how much software they would deploy in the future, influenced by the executive suite's objectives, than underestimate, essentially "gaming" Oracle to get a UDL at a lower price point.
Opinion #2
However, what if we are mistaken and our clients deploy more than we estimated for whatever reason?
What's the worst thing that could happen?
We would have clients that are using more Oracle software than we could have ever imagined,
By using Oracle, these clients are not using our competitors.
We would have satisfied clients because Oracle enables them to accomplish their goals on time and under budget.
We would have happy clients who feel they got an even better value than they projected for the UDL.
With an expected customer lifetime exceeding 15 years, if this UDL is viewed as one-sided with all of the value on the client's side, it's only for three years.
When we propose our renewal UDL, we will have the prior three years of data for our forward projection and pricing.
Taking It To The Streets
Tony got the okay to proceed.
I was ready to jump on this, but Donnie was too.
He and his team closed the first Oracle Unlimited.
"You've Got Mail" should give you a hint (not my account, so the name is not mine to give.)
He was the first mover and is to be commended for blazing the trail for all of us.
That must make me a fast follower.
Our team closed two of the first five and four of the first ten UDLs.
I have a story for each of them.
We added a wrinkle that would become a standard.
We used John with Oracle Finance Division to deliver a payment plan that matched cash outlay with projected deployment.
Our customers saw value in this approach.
What about Greg down in Atlanta?
When Donnie and Ken circled back with him, his expectations did not align with where we landed with our UDL concept.
Ironically, SBC bought BellSouth in 2006, bringing Greg and Cingular back under my responsibility.
In 2007, my team helped consolidate what is now AT&T into a very large ULA.
The unlimited concept was so well-received by our accounts that within three years, HQAPP had made it a standard, renamed it to Unlimited License Agreement (ULA), and produced a boilerplate agreement, sales guides, and sales training.
The ULA generated billions in revenue for Oracle.
Deservedly so, Tony became known as the "Father of the ULA."
Lessons Learned
1) Solve problems and get paid.
2) Impossible is only the degree of difficulty. Don't be afraid to take on challenging projects.
3) Sometimes, the toughest sale is not with your customer.
4) Teamwork. There is no better feeling than being a part of something bigger than you.
Thank you for reading.
Jeff
When you think “sales leader,” I hope you think of me.
If you like what you read, please share this with a friend.
I offer my help to sales leaders and their teams.
I possess the skills identified in this article and share them as part of my service.
In my weekly newsletter, Win More, Make More, I provide tips, techniques, best practices, and real-life stories to help you improve your craft.