What’s the news: Buried in the Q4 and all FY announcement of Oracle was the CAPEX figure for Q4 of the last Fiscal year. And it was for the first time in the last eight quarters – more than 2B. YoY it was a close to 1B bump from 1.1B Q4 last year to a little more than 2B this Q4. CEO Saffra Catz seems to like 1.6B CAPEX spend, which was the number in in 5 of the last 8 quarters. But two quarters were just 1B, now Q4 2B+.



 

Why it matters: You can’t build out a cloud in the real world without massive CAPEX investment. Look at the AWS / Amazon, Microsoft Azure and Google numbers. On the flip side Oracle execs are smart enough to not throw good money after bad money – e.g. put CAPEX $s in a non-working cloud infrastructure. So, at any chance given to me since 2014 I asked CEO Mark Hurd – when will Oracle spend more CAPEX? The answer has always been evasive… But at its OpenWorld conference, Oracle unveiled the 2nd generation of its IaaS solution. It now seems to get the CAPEX it needs to get real. 



 
From Oracle Q4 2017 / FY 2017 earnings call material

MyPOV – Good to see Oracle finally putting the CAPEX where its ambition is. PowerPoint and keynotes are cheaper than datacenters, Oracle knows this – but as said above, why spend into something that you know will be replaced (e.g. one year ago, internally, IaaS Gen2 was happening) and will have to be replaced later… So, this is good commercial acumen. But it’s only one quarter and Oracle will need a string of 2B CAPEX quarters (or even more) to make IaaS Gen2 a real offering around the world. It was interesting to see earlier this year that Hurd claimed higher data center efficiency due to the Oracle engineered chip to click stack… it was worth AWS data center guru James Hamilton to respond (worth the read here). In short: Data center efficiency matters.



 
Larry Ellison at OpenWorld 2016 - with TCO claims of Oracle Gen2 IaaS vs AWS
Here is one more ironic aspect in the IaaS race: AWS, Microsoft, Google and IBM (as the other top 5 IaaS providers) – should all (of course secretly) be pulling for Oracle. Why? We estimate 30-40% of enterprise critical systems are running on – or are inextricably linked to an Oracle database. So far – nobody has moved a substantial amount of these systems – not AWS (Oracle AMI since 6+ years), not Microsoft (heck, Microsoft even brought Linux into Azure to run Oracle – 4+ years ago). Why did no migration happen? Re-implementation and testing of enterprise grade systems has multiple red tapes on them. Never break a running system… so, enterprises did not move these systems. Now, if Oracle cannot move these system with IaaS Gen2 / DBaaS, and the help of the pretty driven (to say it nicely) Oracle Salesforce… then these systems will stay on premises – for a long time. It would be withering 10% reduction year over year (the rate of replacement of running, enterprise critical systems. Good news for the Cisco, Dell, HPs etc. and all who make money with on premises IT investments. Not so good for AWS, Microsoft, Google and IBM… so therefore they maybe (secretly of course) pulling for Oracle to be successful to move its database to the cloud. Once they are there – even if on Oracle IaaS – competitors can start chipping at Oracle in the cloud… we have seen that game for decades already.

CxO Advice: This is good news for a CxO running Oracle systems. When your vendor’s IaaS is more efficient and becomes real – then you are in for better (and likely cheaper) cloud computing. And it is good for the market overall, as more competition improves offerings and keeps the vendors sharp, all to the benefit of enterprises. CxOs running the Oracle database should consider pilots and collect experience with DBaaS on IaaS gen 2. Enterprises can’t miss out on an option to run critical systems with lower TCO. If you are not an Oracle CxOs, look on what is happening, and ask for similar performance and TCO for your RDBMS running in the cloud. Potentially take advantage of aggressive Oracle pricing – migration is a two-way street.





 
 

 

Business Research Themes