- SAP has made enormous claims around HANA, but data points from the field contradict these claims.
- In this article, we cover one of these case studies.
We have covered in the article, How Accurate Was SAP on HANA Being a Perfect Fit for ERP?, that HANA is a poor fit for ERP systems because of the fact it is weak in transaction processing performance. However, transaction processing is most of what an ERP system does.
Here are some direct quotes from someone who reached out to us.
“ECC / BW Transaction codes take more time on HANA, than the same transaction code accessed in R3 (4.6c) on DB6 and the same transaction codes in other SAP products on DB6 also taking much less time to access. This is something which is known within the team. Add to that, in 2018, SAP’s own team which is on-site asked them to move from multi-node to single node for two of the ECC systems due to frequent issues with the earlier multi-node setup. and during the migration from multi-mode to single-node.”
What is interesting here is that while ECC transactions code should take longer than on HANA. But what is curious is the report here is that BW transaction codes also take longer. However, BW is supposed to be the one area where the performance is better than Oracle or DB2.
Constant Support Issues with HANA
There were issues which lasted for over 2 weeks and this despite doing working sessions with SAP support for over 2-3 days.
HANA 1.0 SP11 was implemented back in 2017 was updated to 1.0 SP12 in 2018 and went live (regional go-lives)
This matches out other data points that bring up the constant factor of the high maintenance overhead with HANA. This is why we have predicted the highest TCO for HANA of any of the RDBMSs that it competes against.
Azure and HANA
“The MS Azure ECC system for a strange reason has been set up on MS SQL DB (not HANA, for reasons unknown), while BW on MS
Azure is on HANA. there were multiple critical show stopper issues for BW and even for HANA on MS Azure due to resource bottlenecks, despite the DB size being only abt 700GB to 1TB at max, whereas the resource allocation was around 8TB.”
This brings up the question related to Azure with HANA. Azure is SAP’s preferred public cloud partner. Yet it does not appear that Azure, in this case, knew how to setup HANA.
On the companies websites, everything looks like it works. It is not until the solution is tested that problems surface.
Here is another example of inaccurate information. S/4HANA is still quite immature, and it is unlikely that Microsoft is using S/4HANA for much of anything but as a demo box. This type of announcement is made to drive the S/4HANA business to Azure. And if Microsoft has mastered using S/4HANA (which uses HANA), why did this case study report such a problem with using HANA on Azure?
This case study tells us an interesting story, which is corroborated by other case studies. Mainly that HANA, in reality, is far away from its marketing claims. But this case study provides new information to us, which is the ability of Azure to support HANA. It should be understood that HANA is a higher overhead database, and there it will be more challenging to set up and maintain appropriately versus other databases that are considerably more stable.
There is very little public communication of issues with HANA. All the information we obtain must be anonymized because things are made difficult for people who report that SAP does not match the marketing claims.