How HANA’s Time in the Sun Has Finally Come to an End
Executive Summary
- SAP has been forced to move HANA into the background of its marketing focus for various reasons.
- Trends shifted away from proprietary databases towards open source databases.
- Marketing claims about HANA being groundbreaking turned out to be false. HANA had no offerings that gave it an advantage over competing solutions, and it proved to have the highest TCO among its competitors.
Video Introduction: The Real Story on SAP’s HANA Focus
Text Introduction (Skip if You Watched the Video)
For several years beginning in 2011, SAP made HANA one of the marketing tentpoles of the company. During this time, SAP constantly pushed HANA onto customers and locking customers into HANA by mandating its connecting without any technical reason to other SAP products. During this period, SAP made an enormous number of false claims. “HANA fatigue” finally set in on the part of customers. You will learn that after HANA did not meet the growth of financial expectations, finally, in 2018, SAP decided to de-emphasize HANA as a marketing centerpiece.
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 Marketing Transition Away from HANA
In 2011 HANA became the primary marketing tentpole for SAP, replacing Netweaver, which had been the primary focus at that time.
The official date where HANA was replaced in this position in SAP’s marketing orbit can be marked as June 5th. That is the first day of SAPPHIRE 2018. This is because HANA was noticeably less prominent at SAPPHIRE 2018 than it had been since its introduction.
SAP Thought it Had Cracked Oracle’s Code
SAP’s obsession with HANA reached a fevered pitch from the 2011 and to 2018 timespan. SAP had actually (I believe) convinced itself that it had done something that it had not come close to doing (which is come up with the “killer app” in the database market). SAP thought that combining a column-oriented (partial column oriented, it later turned out) database combined with more memory had never been executed as had been done by SAP. As is well known, SAP acquired all of its technology for this design and my analysis, which is partially documented in Did Hasso Plattner and His Ph.D. Students Invent HANA?
SAP’s contribution to the combined analytics processing and transaction processing database was to market it. This powerful marketing by SAP caused Oracle and IBM to move resources into developing such functionality in their databases — a move which I think was a misallocation of resources. Research by Bloor Research, which I analyzed in the article How Accurate Was Bloor on Oracle In Memory, covered the extra overhead of Oracle’s in-memory offering.
SAP Pays Forrester to Make a New Database Category
SAP paid good money to try to make mixed OLTP and OLAP from one database “a thing,” going so far as to pay Forrester to create a new faux database category called the “transanalytical database.”
And surprise, surprise, HANA was declared a leader in this new database category! We covered this in the article What is a Transanlytical Database? (It is a new database category, specifically for those that don’t know much about databases.)
This is something that Bill McDermott crowed about on the Q4 2017 earnings call but failed to point out that SAP had paid Forrester for this study.
One wonders how much in market cap was added because of this report and how much that added to how many stock options were exercised by the top executives at SAP. Even if it were a tiny number of percentage points, it would still make whatever SAP paid Forrester an absolute steal.
The Trend Away from HANA
Databases have become increasingly diversified since HANA was first introduced. Because of IaaS like AWS and Azure, it is now increasingly easy to spin up multiple database types and test them. Moreover, the most significant trend is not patent software databases but open source databases. Also, since HANA’s initial introduction, the trend towards open source databases has only grown. This is offering more different database types than ever before.
There is even now a database focused on something called horizontal scalability and disaster recovery called CockroachDB. There is more opportunity than ever before to access specialized databases with different characteristics. And due to IaaS providers, these databases are far more straightforward to provision and test than in the past. Open source databases can be spun up and tested, and distributed like never before. Yet, the presentation by SAP to customers that there are only two database processing types (analytics and transactions) that they need to worry about and that HANA covers the bases. SAP could not have picked a more incongruous messaging and strategy around databases if they set out to do so from the beginning of HANA’s development.
The best transaction processing database is a row-oriented database. The best analytic database is a database like Redis or Exadata. If one tries to get both out of a single database, compromises quickly ensue, and maintenance costs go up.
What the HANA Experiment Illustrated
For many years since HANA was introduced, I had quite a few people who had little experience with databases telling me (and anyone who would listen actually) how earth-shattering HANA would be. These bold statements were brought forth by people with often no experience with databases. Through many conversations, it became evident that the person often was repeating what they heard from SAP. But the problem was that SAP made statements about HANA and databases in general that were in error.
This taught me that a sizable component of the enterprise software population is willing to not only discuss things but be highly confident in presenting stuff for which they have no way of knowing if they are correct. It means that a significant component of those that work in SAP is faking knowledge.
The proposals were so off the wall that I was subjected to that they needed their laugh track. I had partners from Deloitte and Capgemini and several other firms. These people would not know the definition of a database index, who have not been in anything but the Microsoft Office suite in several decades, telling me with great certitude how HANA would change everything.
“You see Shaun, once we columnar in-memory databases are used for transaction systems, the entire BI system goes away.”
Many of the SAP executives’ statements or SAP consulting partners seem like the Jimmy Kimmel Live segment called Lie Witness News. I could describe it but see for yourself.
These people have an opinion on the US invasion of a fictional country without asking, “where is Wakanda?” If you ask these same people, “do you think SAP’s HANA database is excellent and better than all other databases,” what answer would we get?
Time to Admit You Don’t Know Wakanda Does Not Exist (and that HANA is not GroundBreaking)?cost
The issue is a combination of dishonesty combined with the assumption that something must be real because it is presented and proposed by a large entity (in this case, the US military being in Wakanda). This happens all the time, and the people that recommend things without checking are often quite experienced. This is, of course, doubly a problem when consulting companies see jumping on whatever the new marketing freight train that SAP has as critical to meeting a quota.
The upshot is that many people who repeated things about HANA without either having the domain expertise to know or without being bothered to check should be highly embarrassed at this point. And these are people in a position to advise companies, which is where the term “blind leading the blind” seems most appropriate. SAP customers need to know if Capgemini, Deloitte, Accenture, Infosys, etc…..were trying to get you to purchase and implement HANA. They had no idea what they were talking about or did not care what was real. As required by the SAP consulting partnership agreement, they were, along with the sales quota incentives they have, repeating what SAP told them. And for nearly everything SAP proposed about HANA, they made it up. SAP not only made up the benefits offered by HANA, but they made up a fictitious backstory of how HANA was “invented,” as we covered in the article Did Hasso Plattner and Ph.D.’s Invent HANA?
HANA’s rise leads many people with only a cursory understanding of databases, talking a lot about databases. Naturally, their statements, promoted by SAP, had very low accuracy. With HANA moving back in SAP’s enormous deck of cards of SAP products, the topic of databases can now shrink down closer to the group of people who know something about them.
That is a positive development.
HANA Was Going to Change the World?
HANA was supposed to change the world. However, what did it change?
If we take just one example, the idea of loading all of the databases into memory, if one looks at the vendors with far more experience in databases than SAP, no one does this. It is wasteful when only a small percentage of the tables are involved in the activity. This is why each database vendor has a group that focuses on memory optimization. And it was eventually determined that SAP says that they load the entire database into memory, but they don’t. Memory optimization still rules the day. This is just one example, I could list more, but outside of marketing, HANA did not change much, and either all or nearly all of its projections turned out not to be true.
The Final Outcome of HANA
Customers who implemented HANA now have a higher TCO database, a far buggier database, and run more parallel databases. After years of analyzing this topic, I can find no argument for replacing existing databases with HANA or beginning new database investments by selecting HANA.
Lets us traverse through the logic because it seems to be tricky.
- Does HANA perform better in analytics processing than previous versions of Oracle or DB2 that did not have column capabilities and ran on older hardware? Yes.*
- Does HANA outperform or have any other associative capability that gives it an advantage against the major competing offerings? No
- Does HANA have the most bugs and highest TCO of any of the offerings it competes against? Yes
- Is HANA the most expensive of all the offerings it competes against? Yes.
*(The topic that SAP has routinely tried to get clients to think that HANA on new hardware should be compared against Oracle and DB2 on old and far less expensive hardware is covered in the article How Much Performance is HANA?)
Where are HANA’s Sales Outside of Companies that Already Run SAP Applications?
Is some explanation for why HANA is not purchased outside of SAP accounts. The sales pitch was that HANA was so much more advanced than competing offerings that not only S/4HANA but other SAP applications could not work to their full extent without it. It would be easy to develop with the HANA Cloud Platform (now SAP Cloud or SAP Cloud Platform) that developers outside of SAP would flock to it because of its amazing capabilities. Right? SAP said all these things and many more.
However, if all of this was true, shouldn’t SAP be able to sell HANA to customers that don’t use SAP applications? Vishal Sikka stated that HANA was instrumental to a wide variety of startups.
Where is that market?
The answer is nowhere. That should give us pause regarding SAP’s claims.
Is SAP Dedicated to Breaking the “Dependency” on Oracle?
SAP justified all of the exaggerations in part by convincing themselves they would help their customers “break” their dependency on Oracle (and, to a lesser degree, DB2). However, one has to question how dedicated one is to “breaking a dependency” when the desired outcome is not to switch dependency to SAP. When a customer buys from a competitor, that supposedly is a “dependency.” However, when a customer buys the same item from you, that is a “relationship.” This sounds a bit like the saying that a person can either be a “terrorist” or a “freedom fighter,” depending upon one’s vantage point.
The Logic for the Transition
If we look at the outcome, HANA is not a growing database.
HANA has not grown in popularity since Feb 2017. Moreover, it has not increased significantly since November of 2015. And let us recall, this is a database with a huge marketing push.
It cost SAP significantly to redirect its marketing budget to emphasize HANA over other things it could be stressing. I have concluded that most of HANA’s growth was simply due to its connection to SAP. If HANA had to acquire customers as a startup, it would have ceased to exist as a product a long time ago. The product itself is just not that good.
The second point is that HANA was enormously exaggerated in terms of its capabilities.
Point three is that some HANA purchases were made to satisfy indirect access claims. That is, they were coerced to purchase. I am still waiting for a Wall Street analyst to ask the question.
“How much of the S/4HANA and HANA licenses are related to indirect access claims?”
Wall Street analysts have a process where they keep away from actually interesting questions.
Diminishing Returns for Focusing on HANA
SAP was not getting a return from allocating so many of its is promotional resources to showcasing HANA. Furthermore, the customers were becoming “HANA resistant.” The over the top HANA emphasis by SAP had become a point of contention and often ridicule at customers (which I learned through my client interactions)
All of this would not have happened without Hasso Plattner. Hasso bet big on HANA, and he was wrong. HANA was allowed to be promoted on tenuous grounds because its champion was Hasso Platter.
In Hasso Plattner’s Book The In-Memory Revolution, he stated the following:
“At SAP, ideas such as zero response time database would not have been widely accepted. At a university, you can dream, at least for a while. As long as you can produce meaningful papers, things are basically alright.”
The problem? HANA has not achieved zero latency to this day. It was never a reasonable goal. And Hasso illuminated something else with this quote. University students are even less willing to push back on Hasso than career database professionals. A fundamental reason is they have much more experience.
The True Outcome of HANA
SAP is now stuck with a buggy database, unable to come close to its performance promises, which has influenced SAP’s development in other areas in a wasteful manner. For example, many of the changes made to S/4HANA to accommodate HANA have not been necessary and have extended out the S/4HANA development timeline. Secondly, the requirement that S/4HANA only uses HANA has both restricted the uptake of S/4HANA and will continue to do so. S/4HANA could be overall much farther along if it was just “S/4” and ran on AnyDB.
Now companies that purchased HANA will justify the purchase (no one likes to admit they got bamboozled) because BW runs faster. However, these same executive decision makers entirely leave out the impact of HANA’s far more expensive hardware in the performance analysis. Companies that purchase HANA for BW don’t test or hire out tests to determine how much the performance benefit is due to hardware. That is how much Oracle or DB2 (and a modern version of Oracle and DB2) would perform on the same hardware.
Instead, they tell me that BW’s performance improved over an eight-year-old version of Oracle or DB2 on eight-year-old hardware because it has much more disk than memory and costs a small fraction of the HANA hardware. So with BW, companies can hide HANA’s performance limitations (although not its maintenance overhead). However, HANA has many problems meeting customer expectations for things that SAP said the performance would skyrocket, including everything but short SQL queries.
This means that SAP will be fighting fires with no HANA performance for S/4HANA for transaction processing and MRP processing for years. If they simply did what they had always done, SAP would have none of these problems, allowing the companies that knew databases to provide the database. As pointed out by a colleague.
“The far bigger threat and loss of income and account control to SAP is from IaaS/PaaS providers, not database vendors. “
This was not at all the SAP’s vision for the outcome of HANA.
Conclusion
SAP was never a database company, and now it looks like it won’t be (a significant one) in the future. And, there is nothing wrong with that. In retrospect, SAP’s acquisitions of Sybase and other purchases (that it made very quietly) that ended up being HANA could have been invested to much better effect by merely fixing ECC issues and upgrading product support.
HANA will still be there, but SAP’s marketing focus is moving on to other things. Right now, it’s unclear exactly which it will choose. C/4HANA is the new kid in town. S/4HANA is still a centerpiece. SAP has so many products, toolkits, announcements, and concepts to promote that SAP marketing is a beehive of activity. However, the overhyping of HANA to promote S/4HANA has subsided. S/4HANA will now be more sold on its functionality (as ECC always was).
What the Future Holds for HANA
SAP has shifted to making the compatibility argument to customers, but not in public. Publicly SAP says that the only application for which HANA is a requirement is S/4HANA. However, the sales reps repeatedly argue that their applications can only work as intended with HANA. We evaluate these compatibility arguments for clients and are always surprised by the new explanations SAP comes up with to drive customers to HANA. The accuracy of these private statements to customers should never be taken on face value but need to be evaluated on a case by case basis.