Why SAP Will Have to Backtrack on S/4 on HANA Database
Executive Summary
- SAP has cut off its customers’ options by restricting S/4HANA to HANA.
- This is limiting the uptake of S/4HANA. It brings up the question of whether SAP will stay with the restriction of S/4HANA to just HANA.
Introduction to S/4HANA Being Restricted to HANA
I have concluded that SAP will have to significantly change direction on the HANA database and S/4HANA at some point. I cannot predict when, but it will have to happen. This article covers this topic.
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.
SAP’s Lack of Progress on HANA
As I pointed out in the article, Has SAP’s Relentless HANA Push Paid Off?, the HANA database is not selling very well. Much of the HANA-based products are not ready to be sold. With the introduction of the Oracle 12C database, SAP has lost any advantage in database processing speed. It is most likely now behind Oracle in processing speed.
We don’t know precisely as SAP is not producing benchmarks for critical processing types — like transaction process, which is mostly what an ERP system does. But we can guess based on the design and other benchmarks. SAP has no reason, aside from a monopoly action, to push other database vendors out of its clients, to not certify Oracle. And other database vendors to be “HANA database only.”
Do the HANA Database Arguments Make Sense?
As I pointed out in the article Getting Clear on SAP S/4 HANA Terminology, many of HANA’s arguments don’t make any sense.
- This is not to say that in some circumstances, high cost and speed hardware is not useful.
- This is not to say that faster hardware in more RAM and SSD is not useful and is called for specific uses.
But SAP’s proposal, which Hasso Plattner first championed, that everyone needs to agree with the idea that the HANA database should be the exclusive database that SAP runs on is, of course, untrue.
How Hasso is So Wrong on Column Based Databases
I have read through many materials on HANA, including Hasso Plattner’s paper A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database. This paper proposes that columnar databases are better in pretty much every way over traditional relational databases. Outside of SAP, it isn’t easy to find a person well versed in database technologies who agrees with this.
The problem is that Hasso is acting as both a computer scientist and a leader at SAP. Therefore a paper written by Hasso is not merely a standard paper in computer science. It is written by someone trying to sell people on the HANA database. His objectivity on the topic is non-existent.
Hasso has an enormous financial bias that a typical Ph.D. in computer science does not have. Also, the paper leaves out so many other aspects that are necessary to the decision among different databases.
Like Drinking Kool-Aid?
So many SAP partners and independent consultants have served as an echo chamber for proposals made about HANA, all of it based on the idea of going with the flow and maximizing revenues. The technological truths or falsehoods don’t seem to matter.
Who Knew the Real Story on HANA Database? (And Carried the Lie)
I can say that a lot of people in consulting companies who were “advising” on the HANA database owe their clients an apology. The more time that passes, the fewer the statements that SAP has made about the HANA database seem to be marketing fluff. And the major SAP partners bought 100% into them and mindlessly repeated them — and included them in marketing literature.
For several years SAP partners went insane and could not stop using the term “simple” at conferences. Finally, SAP dropped the whole simple theme as it was becoming a joke. It appears that many of the most senior members of these organizations had no idea they were even saying anything false.
SAP has also been massively exaggerating the acceptance of the HANA database. This quotation is from 2014, which looks even more inaccurate from this vantage point.
“Meanwhile, SAP also saw higher adoption of its HANA platform with more than 3,600 HANA customers and over 1,200 customers for SAP Business Suite on HANA. The company did not, however, disclose its revenue from the in-memory database platform. It said in the last quarter that it had reached 3,200 HANA customers, including close to 1,000 for the business suite.”
“Hana has taken hold,” McDermott said during the call. “We don’t have to prove that it works.” – InfoWorld
HANA Works for How Many SAP Applications?
HANA database does work for some applications, but for very few. HANA database works on BW. HANA database operates on the Finance module in S/4. BusinessOne (for some strange reason) has been ported to the HANA database. However, there are many applications for which the HANA database does not work. There are also many applications like CRM or Concur, or SuccessFactors, for which in-memory computing is just a waste of hardware resources.
Regarding effect, here is the following quotation from someone who has implemented the HANA database on both ECC and SCM.
“And don’t see much on transaction side, biggest change is aggregating tables. We have already Hana database on both ECC and SCM boxes, We don’t see super speed! I think you can talk about the super speed of SAP apps on HANA database, until you actually have it. Database speed does not directly translate to usable speed.”
I can echo that statement; seeing some of my clients port BW to the HANA database is undoubtedly faster, but it has not brought a brave new world to companies’ analytics. The biggest problem they face, which is the massive backlog of reports and other work that seems to grow every few months at companies, has not been addressed by the HANA database.
SAP’s Positioning on HANA to Replace Oracle and Other Databases
SAP has invested hugely in HANA. SAP has been using a scare tactic to spook companies off of Oracle.
- The argument has been that Oracle can’t keep up with SAP’s innovation. In the article, Faster HANA or Oracle 12C, I provide information indicating this most likely untrue.
For years SAP proposed that Oracle had no future for running as a database under SAP applications. The way that this was justified was to require that other database vendors primarily design their databases like HANA.
How SAP’s Technology Opinions Changes Depending On What Makes Them The Most Money
This substantially changes the game from where SAP was agnostic as to the database to where SAP bought Sybase and had a product to sell. Of course, it changed more dramatically with the introduction of the HANA database. This policy change is explained in the book SAP Nation 2.0:
“R/3 avoided database specific features like stored procedures. This allowed customer database portability choices. In fact, that was SAP’s rallying cry for over two decades. But with S/4, SAP is reversing direction and is moving logic from he application layer into the HANA database. Dr. Plattner defended the move as a way to simplify the code. In a comment to a blog post he said, “That R/3 didn’t use stored procedures is true. The ERP version of the suite on HANA not only dropped the transactionally maintained aggregates and all redundant materialized views, but heavily uses stored procedures and other libraries of the HANA platform. The application code is being simplified dramatically. The transactional performance increases accordingly.”
This is unknown to many but is a serious step back for databases, which have, for some time, have enjoyed application independence for some time. The application interacts with the database with a common language called SQL. SAP is proposing that while its applications will use the common language now, it changes the standards on what databases it will certify.
Should SAP be Deciding The Database Customers Purchase for SAP Applications?
But is this for SAP to decide? SAP may propose that its applications will run better on its HANA database than on a competitor’s database. And a competitor database may feel free to claim the opposite. SAP’s position on the HANA database, which has softened recently, brings up whether SAP has the right to decide for customers what database they should be using. If so, could say a database provider like Oracle does the opposite.
Couldn’t Oracle say that only its applications should be running on its database? No doubt, Oracle’s opinion is that all their applications are superior to all SAP applications. So why not merely disallow any application but those sold by Oracle to run on Oracle? It is a hypothetical question, and Oracle would lose business from doing this.
This is an exciting repositioning of the question. It highlights that vendors should not be prescribed to customers what they run with the application or database they are selling.
HANA as a Database to Beat All Competitors
There is an essential distinction between SAP and other database vendors. Different database vendors sell into accounts where they do not control the application layer. SAP does not. As some have claimed, is it true that the HANA database is so competitive with other databases that companies desire it outside of those that use SAP? SAP HANA is not marketed to and not used by anyone but companies that run SAP applications. So how competitive is the HANA database then? That is, how much superior technology and excellent value is the HANA database if it can only be marketed to SAP customers? Think about it. SAP has proposed its world-beating database is so superior, so why not use it for non-SAP applications?
It should be remembered that HANA, a good part of SAP’s database products, comes from Sybase. And when Sybase was independent of SAP, Oracle did not have a problem keeping up with them. It is just unlikely that SAP, which has never had a reputation as a database vendor, has created so much innovation in their database layer that SAP’s applications should not be ported to other databases.
What Backtracking Will Mean
As a strategy, the HANA database was never a safe bet if one looks at enterprise software history. This point is brought out in the book SAP Nation: A Runaway Software Economy by Vinnie Mirchandani:
“Dave Kellogg, a former SVP of marketing at BusinessObjects an now CEO of cloud EPM vendor, Host Analytics, comments: “Application companies should do apps. They rarely build good platforms. Salesforce had numerous disasters with specialized database attempts and they finally gave up and just stayed married to Oracle. Besides, platforms are commoditizing and cloud-izing. Despite misleading marketing, HANA has virtually nothing to do with the cloud. It is a column oriented database system. So, if HANA is the answer to the cloud threat, it’s not a good one.”
Position on Putting S/4 on Oracle (And Other DBs)
SAP will inevitably have to back off of only porting S/4 to HANA. So companies should have no concern about waiting until SAP changes their policy on Oracle.
Conclusion
SAP should have never made HANA a required purchase for S/4.
S/4 has not been released as a suite yet in any complete form, so this issue has not been as much of a problem. And SAP has not lost that much business by limiting S/4 to HANA. But, whenever SAP completes S/4, and it is ready for a “normal” release (that is, it is a non-beta product ready for non-parallel or sidecar implementation), the issue of SAP’s unwillingness to certify Oracle 12c and other alternatives will become a more significant issue.
Curious about the reality of S/4HANA implementations? See our S/4HANA Implementation Study for real story and details on actual S/4HANA implementations.