Reflecting on SAP's huge bet on the cloud

I'm a cloud advocate - I've written elsewhere about its impending inevitability.  But, even if it is a sure thing, that doesn't mean that the journey is going to be easy.  At this point, I'm thinking there are really only two types of companies*:

1. Companies that have policies in place to adopt cloud technologies for specific applications and use cases.
2. Companies that have policies that explicitly forbid use of the cloud under any circumstance - but their employees are using the cloud anyway.

The second type are more widespread than you might think (furtive use of Dropbox anyone…?).  But, SAP is clearly hoping there's more of the first type of company - in fact, the company is pretty much betting the business on it.  HANA, SAP's four-and-a-half year old in-memory database, is the foundation for everything else it does.  S/4HANA (announced February 3rd 2015) is the latest incarnation of  SAP's business suite (ERP, financials, analytics etc.) based on HANA. 

It's significant then that S/4HANA is a cloud-first offering - there will be a new S/4HANA release for the cloud roughly every three months.  On-premise customers will have to make do with a new release every 9-12 months.  Reality is though, many corporations are still anxious about the cloud.  It's new - and what about the security issues of turning data over to a third party and accessing that data over the internet?  I'll come back to those objections later at the tail end of this piece.  Objections aside, there are three compelling reasons for considering using the cloud - SAP's or anyone else's:

• Time to value.  Simply put, the cloud enables you to get projects done faster.  Here's an  example I lifted from SAP Sapphire this week.  Florida Crystal, a private company produces 7m tons of sugar a year.  Don Whittington, VP and CIO at Florida Crystals, has a simple mantra - which happens to be the same as SAP's of the last two years:  Simplify.  When the company moved its SAP Sales and Operations Planning application to S4/HAHA it took just 90 days.  How long would it take to do a similar upgrade on-premise? 
  
  There's a similar example I often use too.  Redshift is Amazon's on-demand data warehouse in the cloud.  The maximum storage I can configure for any Redshift instance is 1.6 petabytes.  Ask yourself this:  How long would it take to procure and commission 1.6 petabytes of disk storage at your company?  Maybe a month, maybe two?  On Amazon Redshift, I can do that in about twenty minutes, end-to-end.  And make a fresh pot of tea while Amazon knits all that storage together for me.  There's just no comparison.
  
  
• Innovate faster.  I've never met a CIO who didn't have a list of projects as long as their arm.  The problem is, with the best will in the world, those projects that lie on the long tail often don't get timely attention.  That's how many cloud business intelligence (BI) vendors got their foothold.  Under-resourced IT departments just couldn't provide some business units with the insights they wanted in a timely way - their projects just never rose to the top of the pile.  So, those departments put those projects in the cloud, either with or without IT's knowledge and consent.  
  
  Kari Escobedo, former VP of enterprise system development at T-Mobile  has a similar story.  T-Mobile was an early and enthusiastic adopter of HANA.  For example, the company used SAP's Object Event Repository, but was only able to get close to real-time event reporting on devices after migrating the application to HANA.  But, the cloud came into its own when a new HANA setup was required to develop the proof of concept for a new application.  Unfortunately, it would've taken four months just to get HANA setup on premise before development could begin.  Kari's answer:  Rent HANA on Amazon Web Services (AWS) and complete the proof of concept in just two weeks.  There's just no comparison.
  
  
• Cost.  In the early days of the cloud, lower costs was one of the arguments made.  To be honest, I think the time to value and faster innovation might be more compelling arguments for many organizations.  However, that doesn't mean there isn't a cost argument to be made.  To revisit Florida Crystals, the company first starting moving applications to the cloud in 2010 - again a very early adopter.  Today, the IT budget is only 0.7% of annual revenue - the typical industry benchmark for IT costs is 4 times higher.  To be fair, maybe part of the difference is that Don Whittington runs a very lean IT shop.  But, that aside, there's just no comparison.

So, what about those security concerns, are they valid?  I'm not sure they are.  Every CIO should ask themselves this question:  Can I afford to employ a better data security team than SAP?  Or Amazon, or Google, or Microsoft, or IBM, or your other cloud provider of choice.  Chances are, in all honesty, you can't.  And, the cloud is big business now.  Amazon recently revealed that Amazon Web Services (Amazon's cloud) is a $5bn business.  (Other cloud providers, including SAP, are less forthcoming unfortunately…).  My point is, any public data breech and that revenue stream is going to evaporate overnight.  Cloud providers are very incentivized to keep your data secure. 

Regardless, security concerns are something that CIO's have to address.  Here are a couple of best practices coming out of Sapphire:

• Kari Escobedo recommended forming a security committee with all relevant individuals early in the game.  Develop agreed standards and share all information on technologies and products under consideration.  If you don't, you'll only have to knock down each individual objection, one-by-one, along the way - and that will ultimately take more time.
• In a similar vein, George Murphy from Lincoln Financial suggested putting security compliance and standards as the very first requirements on any RFI or RFP you issue.  You might as well address those upfront, because if the vendor can't meet them, you won't be reading any further...
   

Data security aside, there's another elephant in the room for many SAP users that I've deftly avoided so far.  What about all those SAP customizations you have?  Yeah, that's a potential problem.  But, SAP have a plan for that.  I don't have full insight into the plan yet, but when I do I'll write about that here.

So to summarize, in my mind the cloud tradeoffs are pretty clear at this point:

• Keep everything on-premise, or achieve faster ROI on your projects
• Keep everything on-premise, or innovate faster

(Full Disclosure:  SAP paid my expenses to attend SAP Sapphire where much of this information was harvested.)

*OK, so there's probably a third group - organizations that haven't got any cloud-related policies at all.