Why SAP Will Have to Backtrack on S/4 on HANA Database
What This Article Covers
- Do the HANA Arguments Make Sense?
- How Hasso is So Wrong on Column Based Databases
- SAP’s Positioning on HANA Database to Replace Oracle and Other Databases
- HANA Database as a Database to Beat All Competitors
- What Backtracking Will Mean
- Position on Putting S/4HANA on Oracle (And Other DBs)
Introduction
I have concluded that SAP will have to perform a major change in direction on HANA database and S/4HANA as some point. I cannot predict when, but it will have to happen. This article covers this topic.
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 exactly as SAP is not producing benchmarks for critical types of processing — 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 the arguments on HANA don’t make many 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 the form of more RAM and SSD is not useful and called for certain uses.
But SAP’s proposal, which was first championed by Hasso Plattner, 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 a large amount of material 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 is difficult 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 as a leader at SAP. Therefore a paper written by Hasso is not simply a standard paper in computer science. It is written by someone trying to sell people on 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?
I can say that a lot of people in consulting companies who were “advising” on HANA database owe their clients an apology. The more time that passes, the less the statements that SAP has made about 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 HANA database. This quotation is from 2014, which looks even more inaccurate in 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 database does work for some applications, but for very few. HANA database works on BW. HANA database works on the Finance module in S/4. BusinessOne (for some strange reason) has been ported to HANA database. However, there are many applications for which 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 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 my clients port BW to HANA database, it is certainly faster, but it has not brought a brave new world to analytics in companies. 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 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 simply can’t keep up with SAP’s innovation. In the article Which is Faster HANA or Oracle 12C, I provide information which indicates 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 essentially design their database like HANA.
This substantially changes the game from where SAP was agnostic as to the database, to where SAP, after it bought Sybase and had a product to sell, and of course changed more dramatically with the introduction of 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. Yet, SAP is proposing that while its applications will use the common language now, it is changing the standards on what databases it will certify.
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 HANA database, which has softened recently brings up the question of 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’s applications. So why not simply disallow any application but those sold by Oracle to run on Oracle? Obviously, it is a hypothetical question, and Oracle would lose business from doing this.
This is an exciting repositioning of the question. It highlights the fact that vendors should not be prescribing to customers what they run with the application or database they are selling.
HANA as a Database to Beat All Competitors
There is an important distinction between SAP and other database vendors. Other database vendors sell into accounts where they do not control the application layer. SAP does not. Is it true, as some have claimed, that HANA database is so competitive with other databases that it is desired by companies 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 HANA database then? That is how much of a superior technology and excellent value is 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 come 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 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, HANA database was never a safe bet if one looks at the history of enterprise software. 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)
It is inevitable that SAP will 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 bigger issue.
References
I cover how to interpret risk for IT projects in the following book.
I cover risk estimation for projects in the following book.
Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk — and learn why these plans don’t work — and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapters
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model
Risk Estimation and Calculation
See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.
Risk Estimation Calculator
