SAP’s Layoffs and a Brightwork Warning on HANA

Executive Summary

  • 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 its senior HANA positions.

  • SAP fired all the top HANA developers
  • SAP fired the director of HANA labs

This adds 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.

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.

  • This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

Important Background on HANA

HANA was an ill-conceived database with 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 his scrappy Ph.D., invented a new database.

Hasso has written this story in several books.

(Video No Longer Active)

SAP frequently removes videos that I expose as filled with lies.

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,” these acquisitions are not listed on SAP’s acquisitions at Wikipedia.

(This video has now been removed from YouTube)

  1. HANA began its life with enormous technical debt because its basic design never made sense.
  2. Hasso eventually picked another supremely unqualified individual, Vishal Sikka, to manage HANA’s development. Vishal Sikka left SAP several years ago for Infosys. Still, 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 lead development on HANA.

Where Does HANA Lead the Industry?

The only area where HANA leads the industry is in marketing claims. At Brightwork, we have performed the most research into HANA of any entity outside of the primary 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-knowledgeable person outside of SAP who 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 prevalent for technology companies to exaggerate 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 a fake innovation, as we covered in the article How to Understand HANA’s Fake Innovation. SAP has been backward engineering other databases and renaming items to hide the backward engineering, as we covered in Did SAP Simply Reinvent the Wheel with HANA? With all of the HANA funding, SAP has been unable to create new database contributions. 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.

More people don’t seem to notice this, which 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 most SAP resources’ brains when a high-ranking person from SAP makes a statement. They don’t 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. It’s odd because, to SAP resources, these claims seem perfectly normal, whereas, to us, they look like the proposals of someone who is merely 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 sold in the market. No other database we track is unstable and requires many different components to run correctly. HANA is held together with various band-aids necessary to get HANA out the door and is 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 is for BW on HANA, but HANA only outperforms older versions of Oracle and DB2 on older hardware. Much of the performance improvement is unaccounted for for more updated and more extensive hardware, as we covered in the article How Much is Hardware Responsible for SAP HANA Benefits?

HANA has no performance advantage over competing databases. It 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 continually talks up HANA’s benefits to customers; however, after extensive evaluation, HANA has no benefit. Any customer that replaces DB2, 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 significant performance degradation in both transaction processing and processing-intensive operations like MRP, as we covered in the article How to Interpret the Performance Problems with MRP on HANA.

The real purpose of HANA is simple. It is to push Oracle out of accounts and capture more revenue for SAP (SAP already upcharges customers for Oracle). Hasso and Larry have been in a multi-decade, deep-seated animosity towards one another. 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 contacting people 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 it would explain many things that don’t seem to make sense without some ancillary reason.

If anyone has read other Brightwork articles, it will be apparent that we are no fans of Oracle. We think Oracle is a monopolistic vendor that the FTC should break up. So, these statements don’t come from any allegiance to Oracle but the databases’ factual characteristics. 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 to influence our technical observations.

The Problem with HANA Development

HANA came out with an enormously exaggerated marketing campaign, as we covered in Has SAP’s Relentless HANA Push Paid Off?

However, in addition to not meeting almost any of the initial claims, HANA still cannot meet these claims, and HANA is simply not making progress toward these claims.

We believe 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 the last remaining founder, he has mainly taken credit for their contributions.

People who listen to Hasso or read his books don’t pay attention because they are 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 ignore the message rather than the individual’s power.

The Firings/Layoffs

SAP has to lay off people in areas where they have been misrepresenting themselves. So if you work in Leonardo in SAP, you will probably 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 meet expectations, other vendors can undoubtedly 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 to maintain employment.

However, most SAP consultants I know and debate don’t seem interested in a competitive market. They wish for HANA to be knighted as the best database globally without ever having to compete. They want 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 its 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, precisely what SAP will now transition to is unclear. But HANA’s exaggerations have finally caught up with it. 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 ages and HANA gets exposed, HANA’s days are numbered as a central emphasis point at SAP. SAP is gravely mistaken if it lends itself to thinking that its past success was based upon differentiated technology prowess. SAP’s primary differentiator has been its ability to create partnerships and place large and powerful firms that can recommend SAP in a financially advantageous position. Essentially, it is a high-functioning machine for the promotion of corruption. 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:

  1. SAP should have stayed out of databases.
  2. SAP should have never developed HANA.
  3. SAP should never have acquired Sybase (more than 1/2 of which was for its mobility, which was not legitimate).
  4. SAP should have course-corrected and dumped HANA when the early problems surfaced rather than doubling down.

Sick of HANA?

Other groups in SAP are 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 item in the article Why Did SAP Move SuccessFactors to HANA?

HANA has been pulling revenues from other applications since its first introduction. As different 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 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

In our view, the recent firings are 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 meets SAP’s claims. And if Oracle cannot do it, it is difficult to see SAP or anyone else 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: databases should be specialized for the processing task.

If I set an impossible task for someone, 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. Those 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 SAP points. 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 to 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 HANA customers stuck with their purchases 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 unstable, and this is eight years into its introduction. The problems now can’t be chalked up to “getting the bugs out.”

This is why we are warning that the jig is up. SAP successfully got short-term money from HANA, but this is not a sustainable strategy. And HANA has been a massive distraction for SAP overall.

What Now?

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 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 sole objective is to maximize their billing hours. And high-end parrots can be replaced for all intents and purposes, 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 could publish what we found as we lack any corrupt association with SAP. That feature 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

  1. 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.
  2. There are excellent multimode databases that SAP could partner with/resell if they don’t want to port S/4HANA to Oracle. They could place their brand on another database and remove 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 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 if any of it is true. If blessed as “standard SAP,” it will undoubtedly get purchased. The only value add SAP adds 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

  1. 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.
  2. 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-analytic applications, it should be removed.
  3. 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, 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 genuinely 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 than true HANA implementation work. In a way, HANA is a dream for consultants because it is the highest overhead database we track, which means that the placed consultants will tend to stay on projects longer. However, HANA stopped growing around 2016, so the projected growth never occurred. Because HANA is not as capable as anything but as an analytics database, resources that 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 planning to extend HANA from BW halted them as they learned more about HANA.

According to DB Engines, HANA is the 20th most popular database, but this overstates HANA’s popularity because part of DB Engine’s measurement method accounts for media mentions, which are exaggerated for HANA due to SAP’s marketing spend. For years, HANA coasted on promises and hype, which 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 makes sense to steer clear of focusing on one’s career.

To find out what these changes mean for SAP development, see this article, Brightwork Notice: Changes in SAP Development Strategy.