- 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.
Introduction: The Real Story on SAP’s HANA Focus
In this article, we will cover the how SAP has finally moved HANA into the background of its marketing focus.
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 the article 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 that were exercised by the top executives at SAP. Even if it were a very small 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, and because of IaaS like AWS and Azure, it is now increasingly easy to spin up multiple database types and test them. Moreover, the biggest trend is not patent software databases, but open source databases. Also, since HANA’s initial introduction, the trend towards open source database 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 simple 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 a 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. It became evident to me through many conversations that the person often was simply repeating what they heard from SAP. But the problem was that SAP made statements about HANA and databases in general that were in error.
What this taught me was that a sizable component of the population in enterprise software are willing to not only discuss things but be highly confident in presenting stuff for which they have no way of knowing if are correct. It means that a large component of those that work in SAP are faking knowledge.
The proposals were so off the wall that I was subjected to that they needed their own laugh track. I had partners from Deloitte and CapGemini and several other firms, people who 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 statements by SAP executives or by SAP consulting partners seem very much 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 very good 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)?
The issue is a combination of dishonesty combined with the assumption that something must be true 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 propose 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 a very large number of people that 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 the “blind leading the blind” seems most appropriate at this moment. Its important for SAP customers 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 true. They were, as required by the SAP consulting partnership agreement, and along with the sales quota incentives they have, repeating what SAP told them. And for nearly everything SAP proposed about HANA, they simply 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?
The rise of HANA lead to many people with only a cursory understanding of databases talking a lot about databases. Naturally, their statements, promoted by SAP, had a very low accuracy. With HANA moving back in SAP’s enormous deck of cards of SAP products, now the topic of databases can shrink down closer to the group of people that 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. The reason is that 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 that implemented HANA now have a higher TCO database, a far buggier database, and they have had to run more databases in parallel. After years of analyzing this topic, I can find no argument for replacing existing databases with HANA, or for 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 was going to be so easy to develop on with the HANA Cloud Platform (now SAP Cloud or SAP Cloud Platform) that developers outside of SAP were going to 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 were going to 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 is could be emphasizing. In fact, I have concluded that really 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.
A 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 purchased. 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?”
Apparently, 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 Hasso 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? Zero latency has not been achieved by HANA 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, and which has influenced SAP’s development in other areas in a wasteful manner. For example, many of the changes that were made to S/4HANA to accommodate HANA turn out to have not been necessary and have extended out S/4HANA development timeline. Secondly, the requirement that S/4HANA only use 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 try to 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 of 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.
No, instead they tell me that performance for BW improved over an eight-year-old version of Oracle or DB2 on eight-year-old hardware that because it has much more disk than memory and cost 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 performance would skyrocket, which include…well everything but short SQL queries.
This means that SAP will be fighting fires no HANA performance for S/4HANA for transaction processing and MRP processing for years. SAP would have none of these problems if they simply did what they had always done, allow the companies that really 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. “
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 issues in ECC 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, through the sales reps repeatedly makes the argument 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 that 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.
Search Our Other HANA Content
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
The Risk Estimation Book
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.
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