Thread regarding SAP layoffs

I'm pretty sure #3 is due to a certain founder of SAP and his silly proclamations during speeches at Saphire. SAP developers and sales people alike generally cringe when he speaks.

8.) SAP also are not leading as a cloud vendor. SCP is a bit of a dud. And cant compete with AWS etc.. SCP is way more expensive and complicated to integrate with other cloud systems and on-prem systems. SAP is not "The" cloud company, they need to refocus on what made them good, business applications for industries and line of business. Leave the cloud stuff for the industry leaders. And they probably need to find some alternatives to HANA. Hence the layoffs. They went in the wrong direction and now need to backtrack. I think this is Bills fault though. They just followed the trend and forced the co. in a direction it was never going to win at. Should have partnered with AWS and kept the focus on getting results out of HANA and their business applications... as well as their culture. Which stinks now. Just my opinion.

And a last thought. they have ASE (OLAP) and SAP IQ (analytical DB). Two great DB's that got gutted and left to rot as development got focused on HANA and SCP.

On point no.1 - Yes. We run HANA as an analytical Database. A third of the memory is used for DATA. The other two thirds are not enough to run the complex queries and models computations. Despite doing HANA best practice and performance tuning it to the max. It just falls short of the sales hype. Period. The memory management in HANA is not good.

2.) Yes, HANA needs people to administer it. You cant leave it on its own. Lots of tuning and troubleshooting.

3.) Yes. It runs on Linux. Always have, always will. BUT There was never any claim that it runs on any platform. They claimed that HANA is a platform though. Which it is, kind of.

• Replication , smart data streaming etc.

• Data + Modeling

• Development Plugins (hosts applications as well)

• • a bunch of other libraries (AFL, BFL, etc.) -

4.) Yes, its too expensive, SAP needs to charge you for the data you store on HANA. Not the full memory size. At least then if you need more computing power to run complex models, you can just buy more memory, instead of forking out MORE license cost.

5.) It needs lots and lots of memory, and CPU. yes. Bit exaggerated statement though about more than the entire customers landscape. Depends on what they had though I guess.

6.) It does. You still need good DB's in the cloud. You can still install it on Azure for instance. If SAP can work on the licensing, they could save HANA. But the 50% split of memory for data and computing is a false claim. They need to allow customers to add more memory without penalizing them on licenses.

Finally point no.7. Yes they are forcing customers to go HANA anyway. Not sure if they can go DB agnostic again....?

HANA is nothing more than a brand and marketing stunt now.

Alll emails and communication from leadership are clear:

previous Strategy “SAP is the Cloud Company, Run on HANA”

New message “SAP is the Cloud Company.”

HANA has issues but it's not a full reversal of course, HANA development in NA and other areas was cut to refocus in Germany and Korea.

As far as what HANA will be, I think SAP has realistically determined that HANA will be for suite applications and that external parties are not going to make the effort to redesign their applications against HANA. A totally different in memory approach that's not backwards compatible with legacy application design has its downsides, and that's one of them.

In a similar vein ERP on HANA at its core was backwards compatible but not fully optimized to take advantage of HANA as a DB. You then got S/4HANA which made non-backward compatible changes (e.g. the customer would have to make changes) like the financial changes (and others in newer releases), but such change is difficult and that's why many customers haven't gone to S/4HANA yet.

1 and #2 - agreed

3 - SAP never claimed this and support has expanded slightly (it can be run on RHEL instead of just SLES, and it can be run on POWER* architecture from IBM on these OSes - but virtually no one wants to buy power hardware because it's about an order of magnitude more expensive than x86_64 hardware of similar performance).

4 I agree with

5 is hyperbolic but HANA does require a lot of resources

6, SAP needed HANA to bolster BW, it was then expanded. The 4HANA products making changes to optimize performance that aren't compatible with AnyDB will force adoption in time (point #7). In the cloud realm, the likely result is that customers are going to be put multitenant unless they pay more for single tenant and that specific optimizations will be made for data volume management to keep database sizes reasonable.