- SAP recently had major layoffs in its HANA group.
- We analyze what this likely means for HANA.
On Wednesday, March 6th, 2019 SAP made a significant change to their senior HANA positions.
- SAP fired all the top HANA developers
- SAP fired the director of HANA labs
This adds on to the recent firing of Bernd Leukert, SAP’s CTO.
In this article, we will review the important implications of these changes along with HANA’s progress.
Important Background on HANA
HANA was an ill-conceived database that had its basic design parameters set by someone entirely unqualified to design a database, Hasso Plattner. As we covered in the article Did Hasso Plattner and His Ph.D. Students Invent HANA?
SAP created a premeditated false backstory to HANA’s development where Hasso with the help of his scrappy Ph.D.’s invented a new database.
Hasso has written this story in several books.
Hasso has retold the story at SAPPHIRE and innumerable articles. This story is entirely false, which means Hasso is lying every time he repeats it. The truth is all of the technologies were acquired a year before HANA was “created” and these acquisitions are not listed on SAP’s acquisitions at Wikipedia.
- HANA began its life with enormous technical debt because its basic design never made any sense.
- Hasso eventually picked another supremely unqualified individual to manage HANA’s development, Vishal Sikka. Vishal Sikka left SAP several years ago for Infosys, but SAP has made very little progress with HANA under the new CTO Bernd Leukert, who was no more qualified to be a CTO than Vishal Sikka or to lead progress on HANA.
Where Does HANA Lead the Industry?
The only area where HANA leads the industry is in the marketing claims. At Brightwork we have performed the most research into HANA of any entity outside of the major database vendors, none of whom can release the information they have because of their partnership agreements with SAP. I have not spoken to a single database knowledgable person outside of SAP that is impressed with SAP’s claims.
HANA is not used outside of SAP customers. This is strange if HANA is what SAP has said it is. If HANA were effective, why would its implementation only be limited to a small number of companies that were already SAP customers before they purchased HANA?
HANA as Fake Innovation
It is very common for technology companies to exaggerated their technological innovation. As we covered in the book The Public Cloud Revolution: How Open Source is Displacing Proprietary IT Mega Vendors, a major strategy engaged in by private sector companies is to pull from the public domain, and pretend that the innovation was theirs. Everyone from pharmaceutical companies to software companies routinely does this. And SAP is a master at claiming credit for innovation they were not involved in.
HANA is fake innovation as we covered in the article How to Understand the Fake Innovation of HANA. SAP has been backward engineering other databases and renaming items to hide the backward engineering as we covered Did SAP Simply Reinvent the Wheel with HANA? With all of the HANA funding, SAP has been unable to create new contributions to databases. And its design is the exact opposite of where database design is going as we covered in How to Understand AWS’s Multibase Versus SAP’s Single-base Approach. This all should not have been that difficult to understand, as SAP’s statements about HANA routinely violated database theory.
Today many of SAP’s statements about HANA can be interspersed with quotes from Dan Quayle or Sara Palin without seeming at all incongruous. Some of the most ridiculous provided by Steve Lucas as we covered in our Analysis of Steve Lucas’ Article on What Oracle Won’t Tell You About HANA.
The fact that more people don’t seem to notice this, shows the deeply propagandized nature of SAP consultants and resources. Any information stated by a high-level SAP resource must be worshipped.
Something odd happens to the brains of most SAP resources when a high ranking person from SAP makes a statement. They don’t seem to ask “wait, does this make any sense?” Instead, the information gets mainlined directly into the brain without filtration. SAP resources have been repeating ridiculous things now about databases since HANA was first introduced. Its odd, because to SAP resources these claims seem perfectly normal, whereas to us, these claims look like the proposals of someone who is simply making things up.
The Problem With the Initial Conception of HANA
HANA was always poorly conceived and it serves no real purpose in the market. Our evaluation of 12 reported HANA implementations worldwide indicates that it has to be the highest maintenance database that is sold in the market. No other database we track is so unstable and requires so many other components to run properly — HANA is held together with various band-aids that were necessary to get HANA out the door and are the natural outcome of highly fractured development leadership. HANA is the black hole of databases, continually swallowing IT budgets. The only moderately successful implementation we have tracked are for BW on HANA, but HANA only outperforms older versions of Oracle and DB2 on older hardware. In fact, much of the performance improvement is unaccounted for more updated and larger hardware as we covered in the article How Much is Hardware Responsible for SAP HANA Benefits?
HANA has no performance advantage over competing databases, has enormous problems addressing the giant memory footprint it is sized for as we covered in the article How HANA Takes 30 to 40 Times the Memory of Other Databases.
The True Purpose of HANA
SAP constantly talks up the benefits of HANA to customers, however after extensive evaluation, HANA has no benefit to customers. Any customer that replaces DB2 or Oracle or other databases with HANA will see no performance improvement in analytics (versus modern versions of DB2 or Oracle even on smaller hardware footprints), but customers will see a significant performance degradation in both transaction processing and in processing intensive operations like MRP as we covered in the article How to Interpret the Performance Problems with MRP on HANA.
The true purpose of HANA is simple. It is to push Oracle out of accounts and to capture more of that revenue for SAP (SAP already upcharges customers for Oracle). Hasso and Larry have been in a multi-decade deep-seated animosity towards one another, and HANA was a way for Hasso to stick it to Larry….perhaps for not stopping and assisting him when his sailboat had mechanical problems in one of their races. Honestly, Hasso is so driven by ego and emotions, this may have been the first seed in Hasso’s mind to start HANA. This hypothesis was first proposed to me by a contact in with many years of experience in the Oracle/SAP space, but who would not want to be identified.
I can’t prove it is true, but if true, it would explain a lot of things that don’t seem to make any sense without some ancillary reason.
If anyone has read other Brightwork articles, it will be apparent that we are no fan of Oracle. We think Oracle is a monopolistic vendor that should be broken up by the FTC. So these statements don’t come from any allegiance to Oracle, but the factual characteristics of the databases. And the same applies to IBM, another vendor whose business practices we are not high on. However, we don’t allow our disdain for Oracle or IBM’s business practices influence our technical observations.
The Problem with HANA Development
HANA came out with a marketing campaign that was enormously exaggerated as we covered in Has SAP’s Relentless HANA Push Paid Off?
However, in addition to not being able to meet almost any of the initial claims, HANA still cannot meet these claims, and HANA is simply not making progress towards these claims.
Our view is that the original sin was having Hasso set the design parameters. As we have repeatedly stated, Hasso is not a technical mind, he is a promoter as we covered in Does Hasso Plattner Have a Ph.D.? The other three co-founders of SAP were more of the technical talent. As he is the last remaining founder, he has essentially taken credit for their contributions.
People that listen to Hasso or read his books apparently don’t pay attention to the fact that he is just not particularly insightful in technology. We get the same impression when reading anything Bill Gates writes. Having large piles of money does not translate into insight, but this seems to be lost on people who don’t actually pay attention to the message rather than the power of the individual.
SAP is having to lay off people in areas where they have been misrepresenting themselves. So if you work in Leonardo in SAP, you are probably going to have to transfer out or get laid off, because Leonardo is dead. And that is what happens to failed products.
The HANA group just got hit with layoffs. However, HANA resources should get laid off. This may sound harsh, but if you have a failed product that sucks the IT budget from other products that do meet expectations, other vendors can certainly claim that they deserve those revenues. That is supposed to be how a competitive market works, not where incompetent products with exaggerated claims are kept on life support so that employment can be maintained.
However, most of the SAP consultants that I know and debate don’t seem to have any interest in a competitive market. They wish for HANA to be knighted as the best database in the world, without ever having to compete. They wish to add hot skills to their resumes and get paid as much as they possibly can.
Things are going to get a whole lot more difficult for HANA. SAP cannot solve the dual mode processing, which puts their overarching strategy for S/4HANA in a serious pickle. And that is just one of the factors working against HANA.
Why The Tide is Moving Against HANA
As we covered in the article HANA’s Time in the Sun Has Finally Come to an End, SAP has transitioned away from HANA as the primary marketing tentpole. However, with Leonardo dead, it’s unclear exactly what SAP will now transition to. But HANA’s exaggerations have finally caught up with it, and furthermore, the internal groups in SAP are rebelling against the overarching focus and disproportionate allocations of resources that go to HANA.
For years HANA has been protected because everyone fears contradicting Hasso, but as Hasso continues to age, and HANA continues to get exposed, HANA’s days are numbered as a central emphasis point at SAP. SAP is gravely mistaken if it leads itself to think that its past success was based upon differentiated technology prowess. SAP’s primary differentiator has been its ability to create partnerships and to place large and powerful firms that can recommend SAP in a financially advantageous position to do so. Essentially it is a high functioning machine for corruption promotion. But SAP increasingly thinks that its success was based upon technological differentiation — and it is getting them into trouble.
There is no doubt SAP would have been better off if the following had occurred:
- SAP should have stayed out of databases.
- SAP should have never developed HANA.
- SAP should never have acquired Sybase (more than 1/2 of which was for its mobility, which turned out to not be legitimate).
- SAP should have course corrected and dumped HANA when all of the early problems surfaced rather than doubling down.
Sick of HANA?
Other groups in SAP are literally sick of HANA.
The SuccessFactors management refused to move to it. The overall topic of SuccessFactors on HANA is rife with controversy, and we cover the topic in the article Why Did SAP Move SuccessFactors to HANA?
HANA has been pulling revenues from other applications since its first introduction, as other applications had their discounts increased to reduce discounting on HANA, which has played havoc up SAP’s internal accounting — making it look like HANA is far more successful than it is.
This was was called out by Peter Goldmacher who figured out the accounting trick that SAP was pulling years ago. He was heavily critiqued by SAP for not knowing what he was doing, and then SAP went black on the issue, which we covered in the article Who Got HANA Wrong and Who Got HANA Right?
Our Warning on HANA
The recent firings is in our view SAP’s recognition that its development strategy/approach with HANA is not working. And it is long overdue. However, the problem is it is difficult to see how HANA can be recovered. It always had impossible design parameters, and it has been flailing about to meet those design parameters ever since. And the problem is, it can’t meet them, which is likely a primary reason for all of the flailing about. Even Oracle, which has far more database experience and talent than SAP has not pulled off multimode databases in a way that meet the claims of SAP. And if Oracle cannot do it, it is difficult to see SAP or anyone else for that matter doing it. Our view is the same as Bloor Research’s conclusion as outlined in our article How Accurate was Bloor Research on Oracle In Memory, which is the same as AWS’s, which is that databases should be specialized for the processing task.
If I set an impossible task for someone, then they won’t reach it. They will be inefficient. This is because impossible goals create dysfunction, and it attracts people like Vishal Sikka or Bernd Leukert who will say anything to keep the lie going and keep their high profile positions by telling Hasso and others that they are making progress when they aren’t. Only attainable goals are motivational. Hasso set the design parameters, but then had no idea how to meet them. He then handed the goals over to two other men who also had no idea how to meet them but said they did.
We have been waiting for SAP to pull a rabbit out of their hat for eight years, but no rabbit has been forthcoming. We have debated SAP resources for years as we covered in the article How to Deflect That You Were Wrong About HANA. It is clear that those people either had no idea what they were talking about or were lying. On the other hand, many people in SAP think they are doing their job if they simply repeat talking points from SAP. One of the biggest disseminators of false information around HANA, John Appleby, who we have lampooned in multiple articles including How John Appleby Was so Wrong About His HANA Predictions, seems to have disappeared from the publishing scene.
And all of those people look quite a bit silly right about now. Finally, the book is closed on whether SAP has any database knowledge that is not far superior in other database vendors. SAP does not.
That article on deflecting about being wrong about HANA was written back in 2016, and HANA defenders have become increasingly scarce.
The Reality of Future HANA Development
So for customers of HANA that are stuck with their purchase and prospects, there is now a very low probability of future improvement in HANA that will allow it to meet its design goals. HANA is still not stable and this is 8 years into its introduction. The problems at this point can’t be chalked up to “getting the bugs out.”
This is why we are issuing this specific warning that the jig is up. SAP has been successful in getting short term money out of HANA, but this is not a sustainable strategy. And HANA overall has been a massive distraction for SAP.
The question is what to do about HANA. Many readers will say…
“Well it is easy to point fingers, but what now?”
So first, we pointed fingers before the fact. The only thing that SAP customers had to do to stay out of this mess with HANA was read our research rather than listen to Deloitte or Accenture, whose only objective in life is to maximize their billing hours. And for all intents and purposes can be replaced by high-end parrots as we covered in the article What is the Difference Between an SAP Consulting Company and a Parrot?
So this is not hindsight, we had foresight on this issue not because we are magic, but because we put the work in to do the research, and because we were able to publish what we found as we lack any corrupt association with SAP. That is a feature that separates us from nearly every provider of information on SAP.
As for specifics of what to do now, we recommend the following:
Tips for SAP
- Multimode databases are no longer a differentiator, and SAP has not gotten the memo because they keep releasing marketing literature that states that it is.
- There are very good databases that are multimode that SAP could partner with/resell if they don’t want to port S/4HANA to Oracle. They could simply place their brand on another database, and get rid of HANA development except for support, porting any application to another database that they can mark up. This is where SAP is moving in the cloud, just marking up other people’s products as we covered in the article How to Understand SAP’s Upcharge as a Service Cloud. SAP could do this with databases also. HANA could be sunset and SAP could just have someone else do all the work, but mark that open source database up many times. SAP can come up with some phony backstory that SAP added some “secret sauce” and most IT departments won’t check anyway if any of it is true. If it is blessed as “standard SAP” it will certainly get purchased. The only value add SAP is adding to database development is its customer base, so why not step out of the way and let someone else figure out databases for you? This would allow them to continue to punish Oracle (a major goal of SAP) and get an even higher margin on databases while not doing anything.
Tips For Companies on HANA
- For Prospects Looking at HANA: Stop any HANA purchases. If even 1/2 of the things we have documented on HANA were true, that should be enough to stall any HANA purchase.
- For Current Customers of HANA: The promised stabilization of HANA is not coming. If HANA is sitting under BW, then it will in most cases make sense to keep it. If HANA is sitting under other non-analytics applications, it should be removed.
- For Prospects Looking at S/4HANA: Customers should communicate to SAP that there is no way they will move to S/4HANA until it is opened up to other databases. We predicted S/4HANA would open to other databases in the article Why SAP Will Have to Backtrack on HANA. , which was written in 2016. All the leverage resides with customers as S/4HANA is still not ready to be implemented, so customers should wait on S/4HANA in any case. If enough customers push back, SAP will change its tune and port S/4HANA to AnyDB. And when this does happen it will be introduced by Bill McDermott as either “showing empathy for” or “listening to” customers. If there were any truly independent SAP user groups in the world, they would advocate for this. But none of the user groups have enough independence to do so.
Tips for Job Seekers on HANA
For years HANA was a hot skill to get on one’s resume. Despite this, there were never that many people working in HANA. So there was always more conversation around HANA, and setting up POCs that true HANA implementation work. HANA is in a way a dream for consultants because it is the highest overhead database that we track, which means that the consultants that are placed will tend to stay on projects longer. However, HANA stopped growing around 2016, so the projected growth never occurred. Because HANA is not effective as anything but as an analytics database, resources that choose to focus on HANA should focus on HANA for BW.
Because of HANA’s technological limitations, HANA will have a hard time growing out of this area. Many companies that had plans to extend HANA from BW, halted those plans as they learned more about HANA.
HANA is the 20th most popular database according to DB Engines, but this overstates HANA’s popularity because part of DB Engine’s measurement method is to account for media mentions, which are exaggerated for HANA due to SAP’s marketing spend. For years HANA coasted on promises and hype, and that can’t continue forever. SAP can only allow HANA to disappoint so many customers before it risks its core business. Therefore, unless resources have a substantial amount of HANA experience on their resume already, it is something that makes sense to steer clear of making a focus for one’s career.
To find out what these changes mean for SAP development, see this article Brightwork Notice: Changes in SAP Development Strategy.
SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos
Fact-Checking SAP’s HANA Information
This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.
SAP Video Accuracy Measurement
|SAP's Statement||Link to Analysis Article|
|HANA is a Platform||HANA is not a platform, it is a database.||How to Deflect You Were Wrong About HANA|
|HANA runs more "in-memory" than other databases.||HANA uses a lot of memory, but the entire database is not loaded into memory.||How to Understand the In-Memory Myth|
|S/4HANA Simplifies the Data Model||HANA does not simplify the data model from ECC. There are significant questions as to the benefit of the S/4HANA data model over ECC.||Does HANA Have a Simplified Data Model?|
|Databases that are not HANA are legacy.||There is zero basis for SAP to call all databases that are not HANA legacy.||SAP Calling All Non-HANA DBs Legacy.|
|Aggregates should be removed and replaced with real time recalculation.||Aggregates are very valuable, and all RDBMS have them (including HANA) and they should not be removed or minimized in importance.||Is Hasso Plattner Correct on Database Aggregates?|
|Reducing the number of tables reduces database complexity.||Reducing the number of tables does not necessarily decrease the complexity of a database. The fewer tables in HANA are more complicated than the larger number of tables pre-HANA.||Why Pressure SAP to Port S/4HANA to AnyDB?|
|HANA is 100% columnar tables.||HANA does not run entirely with columnar tables. HANA has many row-oriented tables, as much as 1/3 of the database.||Why Pressure SAP to Port S/4HANA to AnyDB?|
|S/4HANA eliminates reconciliation.||S/4HANA does not eliminate reconciliation or reduce the time to perform reconciliation to any significant degree.||Does HANA Have a Simplified Data Model and Faster Reconciliation?|
|HANA outperforms all other databases.||Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.||How to Understand the Mismatch Between HANA and S/4HANA and ECC.|
The Problem: A Lack of Fact-Checking of HANA
There are two fundamental problems around HANA. The first is the exaggeration of HANA, which means that companies that purchased HANA end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.
Being Part of the Solution: What to Do About HANA
We can provide feedback from multiple HANA accounts that provide realistic information around HANA — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how companies end up paying for a database which is exorbitantly priced, exorbitantly expensive to implement and exorbitantly expensive to maintain. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.
If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.
The major problem with companies that bought HANA is that they made the investment without seeking any entity independent of SAP. SAP does not pay Gartner and Forrester the amount of money that they do so these entities can be independent as we covered in the article How Accurate Was The Forrester HANA TCO Study?
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other HANA Content
Getting to the Detail of TCO
The Mechanics of TCO
- Understand why you need to look at TCO and not just ROI when making your purchasing decision.
- Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
- Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
- Learn why ERP systems are not a significant investment, based on their TCO.
- Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
- Appreciate the importance and cost-effectiveness of a TCO audit.
- Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
- Chapter 1: Introduction
- Chapter 2: The Basics of TCO
- Chapter 3: The State of Enterprise TCO
- Chapter 4: ERP: The Multi-Billion Dollar TCO Analysis Failure
- Chapter 5: The TCO Method Used by Software Decisions
- Chapter 6: Using TCO for Better Decision Making