What SAP Moving to the SAP HANA Cloud Means

ByPrimary Researcher

Executive Summary

  • SAP has been trying to move HANA to the cloud.
  • We will explain the implications of this movement.

Video Introduction: HANA Cloud

Text Introduction (Skip if You Watched the Video)

There is a lot of information of questionable accuracy given out on the HANA topic that is provided to the market by SAP, SAP consulting firms, and IT media. Some of the data is difficult to verify as one does not either have access to the HANA application in question. In other cases, one cannot test the HANA system. This is because of a lack of skills, bandwidth, etc. However, additional information is easy to observe as incorrect because it is not logical or conflicts with other information. This applies to SAP statements about HANA cloud. You will learn about the accuracy of SAP on their statements related to HANA cloud.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

  • This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

Conversation on HANA

I was recently interacting with someone who was proposing HANA for a client. At one point, I brought up the expense and complexity of HANA as factors to consider. The person I was speaking with had two bizarre responses.

  • His first response was that I should not be focusing on cost because HANA was so much better than everything in the market.
  • His second response was that complexity should not be a focus because SAP will move to the cloud.

Eliminating the on Premises HANA Instance?

I don’t understand this second comment at all. I find it quite disturbing because while SAP talks up its SAP HANA Cloud plans, very few native SAP implementations are actually in the cloud. The exceptions being for products that were already cloud products as they were acquisitions like Success Factors.

If we look at Success Factors or Hybris 0r Concur or Ariba or ByDesign or BusinessOne — SAP applications sold in the cloud, HANA would not do much for these applications requests as they are naturally low in processing usage and memory overhead.

ByDesign no longer sees development. BusinessOne, often thought to be a native to SAP, was acquired a long time ago, as was Ariba (both of which would be a waste to put on HANA). Four of these (not Ariba or Hybris) are low priced products and are not the core of SAP in any shape or form.

And most of the HANA applications that are sold are still marketed as on-premise.

Given all of this, let us look at the logic here for a moment of not working about HANA’s extra complexity because SAP is moving to the cloud.

  • If SAP is eventually moving to the cloud, why is anyone buying on premises HANA servers? So they can be decommissioned within a few years?
  • The idea that you can buy applications in the cloud argues against buying on premises HANA solution now.

SAP HANA Cloud vs. HANA Battle for SAP Marketing Message Supremacy

There is an apparent disconnect between SAP’s twin strategies of pushing HANA combined with putting out the cloud’s vision. This is because SAP is both telling customers that the backend is critical to be emphasized while promoting the idea of moving to the cloud, where the backend disappears into the background. Or, more correctly becomes a service managed by the software vendor or some infrastructure partner like Amazon Web Services.

How Hosted Solutions Work

SaaS/cloud solution providers work fundamentally differently from on-premises vendors. The arrangements change, and the model is subscription based so that the upfront costs are far lower.

Let me provide an example. I use a web host for this website. Occasionally I run into a performance issue. I communicate this issue to my web hosting company, and then they respond that something is out of date or some new software can be installed on the server. I typically don’t know what they are talking about, but I approve the change/update, etc… and the performance improves, and…well, that is the end of the story. The boring story, I know. It is boring in the best way possible because I have no interest in worrying about the infrastructure behind my website. I know just about zero about the web hosting technologies and want to keep it that way.

In a managed environment like I just described, all the customer has to know is that they are unhappy with the performance, and they want a change to occur to improve the performance. This is the same way that SaaS/cloud vendors operate. They take care of the details, and the customer gets to focus on getting value out of the application.

The Productivity Advantage

SaaS/cloud vendors have a massive advantage because they control and tune the environments for their customers. The hardware that is used per customer is smaller because of this efficiency.

There are all types of productivity benefits from the labor specialization of having on group control applications for so many customers. Instead of the decentralized model, called on-premises, where the individuals in the client’s IT department maintains substantially a single implementation of many different applications.

This is not discussed much in enterprise software because economists, by in large, tend not to study enterprise software. (1) However, here is the short version of the benefits of labor specialization and its relationship to SaaS.

A Primary Ingredient to Productivity

Job specialization is a primary reason for improved productivity in all parts of the economy — from plumbers to web designers to hairstylists. The reason for this is that the more someone can focus on being good in one area, the higher their productivity and quality.

The SaaS/cloud application model just allows for a higher degree of labor specialization. This is because a team that manages many customers for a single application is far more efficient than the same sized team managing multiple applications for a single client.

All of this is why training your customers on all the infrastructure of your application, how it is differentiated, how you need to have HANA is just a distraction when one moves to a SaaS/cloud application model. 

SAP HANA Cloud in the Background?

In the article titled Has SAP’s Relentless HANA Push Paid Off?, I proposed that HANA should simply become an inherent property of the application. And it isn’t easy to see why users, functional consultants, and VPs of buying firms should need to go through the litany of infrastructure details. This is how Tableau and Teradata market their applications (with the support available for discussion, but as a background topic), which I covered in the article How SAP HANA vs. Teradata and Tableau Market Backend Technology.

Placing the infrastructure ahead of the application, particularly for a company focused on selling applications, is…well, I think quite strange and really can’t be successful.

SAP HANA Cloud Costs?

So let us discuss the costs of moving to the SAP HANA Cloud. We can discuss all types of options, but once the costs are included, things become much more clear as to what is feasible.

SAP has declared the total cost of ownership (TCO) of cloud costs, which are TCOs for HANA in the cloud. BlueFin Solutions provided estimates which I think are directly from SAP (through John Appleby, who writes extensively on HANA).

The TCO for four years are the following:

  • $1 million for 1TB HANA Cloud Base
  • $2.7 million for 1TB for HANA Cloud Platform
  • $4.8 million for HANA Platform
  • $5.9 million for 1TB for HANA Enterprise.

So, it turns out SAP HANA Cloud is quite expensive. I have not compared these costs to the TCO for on-premises HANA because I don’t have the numbers handy.

Moving to the Cloud

SAP wants to move to the cloud, but two different areas of SAP must be considered when analyzing this statement:

  1. The native SAP applications
  2. The acquired cloud-based applications

SAP is not moving HANA customers to the cloud; SAP is not moving any significant number of clients to HANA in the cloud or on-premises.

SAP may be in for a shock, but cloud applications don’t sell for the same price as on premises, and the majority of SAP’s applications have not been subject to SaaS competition.

This is touched on in this quotation by Vinnie Mirchandani in the book SAP Nation:

“When you compare how nicely IT costs via SaaS application…have dropped in the last few years, you have to ask why those in the SAP economy have not followed that trend.”

I have an answer to Vinnie’s question, or at least I think I do. It is because SAP is protected from marketplace pressures for the majority of the applications that it sells. However, if SAP continues to acquire SaaS applications, and SaaS makes up more of the portfolio, this will change.

Go to top

Conclusion

I hope this article has successfully made the case that it is not so simple to say that.

“SAP wants to move to the cloud,”

..when we are referring to the native SAP applications. In many cases moving to the cloud is expensive for clients when HANA is involved.

When we talk about applications that were already in the cloud when SAP purchased them, the story is entirely different. But the two stories cannot be blended because they are very different situations. What I consider to be “real SAP” are internally developed applications. I am not sure what to make of these newly acquired cloud-based applications yet, and SAP’s actions seem to demonstrate that they often don’t either.

However, let us circle back to the main point. And that is that the complexity of SAP HANA is still very much an issue that must be considered and evaluated independently for each application because while many options are often discussed during sales pursuits, most HANA is sold as on-premises.