Some thoughts on Cloud pricing models
As most of us probably know SAP recently announced the SAP HANA Enterprise Cloud (HEC), a move that caused quite a bit of an echo on the web. Making a living as a Cloud Platform Evangelist at SAP I try to stay at the pulse of the industry and hence I have been doing lots of reading the last couple of days.
Can’t help it, but sometimes I get the impression that many critics are drawing hasty conclusions based on narrow-minded definitions reciting articles they picked up and then writing tabloid-like “bash-ups” just to get a headline and some attention. Reading those I cannot help but be reminded of a great quote from the movie Ratatouille:
“In many ways, the work of a critic is easy. We risk very little, yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read.” – Anton Ego [REF]
One particular piece that made me scratch my head was this article titled Google And SAP: Two Very Different Cloud Strategies on readwrite.com, which was heavily based on a blog post from Forrester’s Stefan Ried called “HANA Enterprise Cloud – Pro and Cons“. The two articles have in common that they both argue that the SAP HANA Enterprise Cloud does not even deserve to be called Cloud as its pricing model is not fully elastic but rather requires customers to bring their own license.
While I would agree that pay as you go (PAYG) is an important aspect of cloud computing I find the arguments rather narrow-minded and they fail to acknowledge the fact that the value proposition of cloud is more than just elasticity. In conversations I have with potential customers I hear that one of the most sought after benefits of cloud computing are time-to-market and faster innovation cycles. In this context, offering a new deployment option for core systems like the SAP Business Suite and BW in a virtual private cloud seems to properly address this demand. Furthermore, operating these core systems as managed services is only one aspect of the SAP HANA Enterprise Cloud offering, yet the one that got the biggest attention from what I can tell.
Another thing I notice in the public critique is that people seem to lack the understanding that enterprise software may not be comparable to other industries and that enterprise scenarios may require a different take on things. Unlike Amazon, SAP does not aim to be the backbone of services like Netflix, which stream HD video on-demand to a constantly growing user base.
Stefan Ried writes:
“The announced Hana Enterprise Cloud follows the “Bring Your Own License” paradigm. While this is great for customers that already have a Hana license and would like to relocate it into the cloud, it is useless for customers that might have largely fluctuating data volumes or user numbers and might specifically use a cloud because of its elastic business model.” – Stefan Ried [REF]
Now, that statement puzzles me: on one hand he underlines the benefit that the BYOL model brings for existing customers and that it may ease their transition to the cloud, on the other he talks about customers with largely fluctuating data volumes or user numbers. I’d argue that the data volumes and user numbers of Business Suite systems are usually not prone to fluctuation and consequently it’s a smart move to first cater to ease of adoption.
Matt Asay writes:
“SAP […] appears hamstrung by its past, in true “Innovator’s Dilemma” fashion. It has so much revenue tied up in legacy deployments of legacy software that even releasing a kind-of, sort-of, not-really cloud offering is the best it can do.” – Matt Asay [REF]
He was at point blank and still missed the mark?!? What he calls the “innovator’s dilemma” I’d rather call the best way to help our current ecosystem to transition to the cloud. Other’s may would call it “innovation without disruption” but the term has been over-used lately I fear. As such I would say that starting with a BYOL model was in fact the “best it can do” to address the current market’s needs!
The one aspect to keep in mind is that in an enterprise context there may be pricing/licensing models that are less disruptive than others and as such may ease the adoption! In (bigger) organizations there are usually well-established processes both in the professional buyer as well as the IT department. Providing a licensing model that is comparable to existing ones helps to speed up the internal decision making and consequently speed up the adoption.
Either way, the SAP HANA Enterprise Cloud is still in its infancy as is the whole industry segment of enterprise software in the cloud. I’m sure that over time and with more demand we’ll see other, more elastic pricing models emerge. Ultimately, I believe SAP would be stupid not to address the whole market from low-touch, fully automated elastic pricing to high-touch individual contracts for large customers.
PS: For those interested in the topic, you may also want to read the blog post of my colleagues Pankaj Kumar “Cloud pricing and pay as you go model“.
I think perhaps this blog misses the point of those voicing these concerns. It's clear that there is value from the BYOL licensing model, and indeed, from the related approach to licensing for the Neo/HANA Cloud/HANA Cloud Platform that requires locking in to a year-long contract. Perhaps these critics aren't clear enough that there is value in this approach, though I think Reid was quite clear about that.
The concern, however, is that SAP hasn't demonstrated it is capable of an elastic approach to cloud pricing that serves a need other than those needs SAP has been serving in the past for it's existing customers. These existing customer have, without a doubt, use-cases for elastic workloads. Even in SAP's EPM platforms, for example, systems have to be sized for month-end processing. Wouldn't it be better to size your EPM system elastically based on expected usage depending on the month/quarter/year? SAP doesn't currently address this need.
The question and concern is whether SAP can adapt it's pricing models to a more elastic approach to compete for these use-cases with cloud providers. It's a valid question whether any of these providers explicitly exist in SAP's core use-cases at the moment (though companies are certainly using custom solutions with AWS and other IaaS providers to meet some of these use cases), but the threat is real and if SAP remains focused on enabling its existing customer base to the detriment of new approaches in the sales and pricing area it could certainly be disrupted by these providers though pricing.
SAP is already being disrupted by cloud providers who provide sales, implementation, and user experience innovations that were not initially attractive to SAP's core customer base. Now these providers are beginning to win within SAP's core customer base as well. The concern is that pricing may be the next frontier of disruption that SAP faces.
Ethan - great comment.
I think even if it would be wonderful to be able to elastically scale EPM systems we need to remind ourselves that these onPremise solutions now hosted in the cloud were not designed with elasticity in mind. Thus even with the best will, being able to upsize on demand just isn't built into the configuration of the solution.
When recently I was given a talk to some students here in Melbourne one evening about "cloud" and SAP's position I made the clear distinction between software that was designed to be run in an elastic cloud and software that was designed to be run on premise in a constrained resource environment. The second kind will never take true advantage of being run in a cloud.
This said, I never heard the messaging that running ERP on HANA on the HEC was "SaaS" or "cloud", so I think SAP fully understand this. In this context, the current licensing models make sense.
What I did also hear, and what you alluded to is the option to run anything that runs on HANA on the HEC. That will - as you suggest need some work.
Thanks Matthias for posting this (I don't know when you sleep you seem to be creating so much good content) and Ethan - again, great comment.
Thanks Ethan for providing your thoughts on this topic and especially for doing so in a very clear and constructive way. Which brings me directly to my core motivation of this blog. It's not that I do not see the need for elastic licensing models or PAYG in specific, not at all. (I'm among the most vocal people pushing for it within SAP may I say!)
What bothers me was more the tone of the blogs I referred to and the fact that while the authors seemed to have a fair understanding of where SAP is coming from and moving forward to, they opted for writing really negative things instead of addressing both sides of the coin.
The point I want to make is that BYOL makes perfect sense to ease the transition for the existing customer base. That's all!
Yet, the vision of HEC is much broader and this is just the beginning. I keep evangelizing that the biggest value proposition of cloud in general and the SAP HANA Cloud Platform in particular is to provide net new customers and partners a chance to join the ecosystem as cloud makes it much simpler to do so (see SAP NetWeaver Cloud (Neo) - The road forward.)
As such I really like your comment as you for one were able to address both aspects of it. I do agree with you that flexible, elastic pricing models are required, matter of fact that was the key message of my closing paragraph!!!
Cheers,
Matthias
Hi Matthias,
Besides elasticity, there is something else to consider.
When discussing an IaaS/PaaS/SaaS offering, technical people like us usually tend to spend more time talking about the "I/P/S" part than the "aaS" part. For me, it should be the contrary. The main (and common) point of these offerings is exactly the fact that you can pay "as a service", i.e. a customer can completely avoid a capital expenditure and pay for a whole SAP project with operational expenditure only. While this is irrelevant for most of us in the other end of the rope, it is often the deciding factor for which IT solution the company is going to chose. The possibility to completely avoid CAPEX and go for 100% OPEX is really interesting for a CFO's financial strategy. Not all companies are willing to have a huge impact in their equity due to IT expenditures. And offering 100% OPEX is exactly where HEC falls shortly...
Of course, no one denies its business value to existing customers and the fact that SAP is going towards the right direction. But, for sure, it's not what is going to save SAP ERP against NetSuite, SAP CRM against Salesforce.com or SAP SRM against Ariba (oops, that last one at least is not a problem anymore 🙂 ).
Cheers,
Henrique.
Hi Enrique,
I think you raised a very important point which on the other side decouples from the Cloud Discussion.
IMHO a bring your own license model is very positive for the user since he "just uses an infrastructure" in a PAYG model but with clear understanding what is his property and what is just "rented". I believe that PAYG has an important advantage over "Flat-Rate" for example. It is clear and straight forward
Matthias has raised a very important point which is in fact probably a key driver for moving to the cloud. Time to Market. This should be a key driver from SAP side as well to push the offering into the market, wake up the partners and make sure they all provide their offerings according to this market need.
When it come on the contrary to the OPEX vs CAPEX model I believe that there are many different options available (after all it is just a financial model) which can serve to the customer as well and which can be complete, ranging from a complete Datacenter Takeover to just leasing equipment and licenses.
Whilst Cloud is going to grow for sure, I am convinced that private cloud models and financial models will be more impacting in the Large Enterprise Space for some time.
Good points! Thanks fro bringing them up.
Hi Henrique,
I guess I'm repeating myself, but I'm not denying the value of a 100% OPEX-based pricing offer. It's indeed important and a must-have in the long run. The point I wanted to make is that I consider it a smart move to start with a BYOL model to ease the transition.
To be honest, I missed that notion in most blogs/articles I read. If people would have written it like that I would not felt the need to write this blog post...
Cheers,
Matthias
The OPEX/CAPEX problem can be solved even without any real cloud in the picture. A vendor can just finance the deal and change it from CAPEX to OPEX . It has been a common practice in the SI and hosting world for many years - and includes things like buying down points etc.
Vijay, the fact that you can finance the payment of the licenses doesn't mean that, in the of the day, they will not be accountable to the company's equity - they will, no matter how many parcelments you pay for them... It's not a financial problem but an accounting one.
I think in the long run - capex and opex discussion would be moot if a customer is going to use the system for longer time. When moving to cloud model a customer might not see the big capex immediately but it doesn't disappear but rather sits in the investments of the cloud operator. And if a cloud operator is going to be a viable business it would need to earn it back. Where the cloud model helps is the faster adoption of a solution without big initial investments along with the ability of the cloud vendor to introduce continuous innovation.
Hi Matthias,
I'd just like to say that I hear and feel your frustration.
But did you really expect anything different from the most emblematic EnSW company entering into one of the "cool" IT areas? No matter how good SAP does it, the anti-EnSW bashers will always throw rocks at SAP for even trying to do so.
I know it's not what you might want to hear right now, but I'd say to use these bad criticisms to get even more motivated into continuing to do the awesome job you and the team have been doing so far. Don't let them get you down, but don't expect any "yay good job" kind of article either...
Cheers,
Henrique.
Hi Henrique,
yeah, it really is frustrating from time to time to read such articles. It's not unexpected, but it still bothers me to see people getting soo much attention without properly doing their homework first. Of course, there will always be people criticizing the "big evil empire" and I'd be naiv to think that will ever change.
Maybe it's also that I'm used to much higher standards because of my peers, which usually write more balanced articles and criticize more on facts.
Anyway, I won't lose sleep over it!
Thanks for your considerations Henrique - appreciated!
Cheers,
Matthias
Hi Matthias,
Thanks for raising a great topic. I see two primary use cases and HEC nicely addresses one of them.
1st - Transitioning Enterprise customers to HANA. - steady-state and fairly predictable growth.
When moving from an application/infrastructure view to the cloud, the behavior of system ownership changes. IaaS provides infrastructure resources, but it becomes the application(service owner) responsibility to manage the VM. This is a critical change, because the model then moves to a SaaS residing on an IaaS. This provides an environment where the enterprise can protect their licensing investments and move them to a SaaS like model. It also creates an environment where if a company decides that they want to bring the SaaS workload back within the Enterprises datacenter, the cost will be only related to migration and infrastructure costs. Potentially, the support model and service deliver (the SaaS offering) will go untouched. Bottom line is that this provides flexibility when thinking about protecting investments.
2nd - Creating an Internet of Things Platform - possibly highly dynamic usage.
It appears that SAP is leaning on its ecosystem to provide the PAYG model. Looking at this announcement from VMWare. http://gigaom.com/2013/05/21/vmware-lays-out-prices-for-hybrid-cloud-offering-now-customers-have-the-ball/
For the IoT platform, if I'm selling toasters with sensors that send data about itself to HANA you don't want to overbuild. The need for dynamics in the pricing model and also includes incremental licencing is exactly the use case for a PAYG HANA model. If SAP is looking toward its partner ecosystem to provide this opportunity I don't see an issue.
The notion that there is only one model to claim one-self as Cloud is no longer a message I worry about. Its about a provider, providing multiple models to consume services. Whether, traditional, public, private, or hybrid is going to be based on the needs of the company.
However, because of that fact its hard for providers to send a crisp message. Its easy if you are just one thing, but when you are ultimately providing a platform, the use cases will vary and message can appear to be unclear.
Certainly SAP needs to make their message more crisp, but I understand and support the strategy they are moving forward with. As the enterprise customer matures and really does NPV studies on their investments, they will want to work with a provider who gives them flexibility.
Thanks for chiming in Sina!
Well, let's not forget that HEC also contains the HANA Cloud Platform (HCP), which addresses the second use-case. Matter of fact, shop-floor systems and sensor-based applications are two of the typical scenarios we mention when talking about HCP. Check out slide no. 19 on my recent presentation on PaaS.
Cheers,
Matthias