Last Updated on May 29, 2022 by Shaun Snapp
- A major part of SAP HANA pricing is database sizing.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Lack of Financial Bias Notice: We have no financial ties to SAP or any other entity mentioned in this article.
- This is published by a research entity.
- 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.
The first thing to know before understanding HANA’s technical details or its pricing is that the information provided by SAP and consulting companies are unreliable. Both SAP and all SAP consulting companies routinely lie and consider it completely normal to lie to their customers/clients. The only thing the SAP sales rep and various consulting resources are measured on is sales of either software or consulting hours. Consulting companies are not independent checks on SAP; they repeat whatever SAP says.
The Importance of Database Sizing in HANA Pricing
Of primary importance in HANA pricing is that before any pricing numbers begin to be applied, database sizing must be performed. This is because HANA is sold per GB. This is quite an unusual pricing for a database.
What this means is the HANA pricing is based on the size or footprint of the SAP database. And SAP has released information that will cause customers to substantially undersize the footprint so that SAP can get their foot in the door with HANA. Customers routinely have to go back to SAP and request more GB, which blows their budget.
Without an accurate footprint estimate, HANA cannot be priced correctly. However, all the information sources on sizing the footprint either come from SAP or come from an SAP partner. Companies that are partners with SAP lose control over the information that they provide to customers. They must not contain information that contradicts the SAP information (read our analysis of the SAP partnership agreement). This, of course, includes companies that are the largest advisors in the space (your Deloitte, Accenture, etc..) to the smallest.
How do we know this?
SAP partners contact me and tell me stories of how SAP threatens to take their partnership away if they don’t follow the SAP rules. No SAP partner can provide accurate information on SAP pricing, SAP HANA pricing, or any other SAP pricing, for that matter.
Therefore, companies are boxed out of accessing accurate information on this topic. Brightwork Research and Analysis is one of the few entities which will publish or provide consulting on this topic. Unsurprisingly, we have no partnership with SAP, and unlike someone like Gartner or Forrester, we take no money from SAP (or any other vendor for anything other than competitive intelligence).
Getting into the Customer’s Business Regarding Archiving
In most cases, when a database is sold, the database vendor sees the sizing as more of a customer determined item. Yet this is not the case with HANA.
Companies have database administration groups that have their views on how frequently and how extensively they want to perform archiving. How much they wish to rely upon compression, etc.. However, because of SAP’s pricing of HANA, SAP is now front and center on the topic of database size and has become quite prescriptive of how they think database administration departments should be managing their databases.
The Deliberate Undersizing by SAP and SAP Consulting Firms
As a synopsis, there are four distinct areas where SAP relies upon to drive footprint reduction, and of these four areas, two are very significantly overestimated by SAP. To see how these areas are overvalued, please see the paper that has been referenced.
Of all the areas where the footprint can be reduced, it is the indexes where most of the space-saving occurs. This is generally between 33% and 25% of the database. Archival can reduce the size of a footprint also. But SAP makes it sound like customers aren’t already archiving, and there is nothing in HANA that makes archival more effective than in any other database.
Secondly, archival is not free.
What Archival Entails
Archival means increased costs in labor to perform the archiving. Therefore, what SAP is saying is that while HANA will do nothing for archival, they can spend more resources on archival if the company desires. This will suit SAP, as SAP can lower the initial purchase price, increasing the potential demand for HANA. Therefore, according to SAP, customers should perform more archival so that SAP can sell more HANA. However, what happens if the customer cannot follow through on the level of archival that they initially commit to?
The database will then grow, and SAP will have its hand out for more HANA license(s). And the problem with this is that while SAP is making greatly exaggerated proposals regarding footprint reduction if they are wrong, there is nothing that the customer can do about it except buy more HANA licenses.
After the initial HANA purchase is made, and once the system begins being used for production (at which point the database will grow), the company has narrowed its options. And, of course, software vendors love narrowing the possibilities of their customers.
That is called lock-in.
You put the customer in a position where they have to buy more from you, or they can’t operate properly.
SAP’s Un-natural Focus on Footprint Reduction
Getting back to the point about total realistic footprint reduction. In our estimate, roughly another 20% reduction from all other sources is attainable, although not without cost.
This enormous focus on footprint reduction is important because, unlike most other database vendors, SAP prices HANA per GB. No other vendor has such an emphasis on database size because no other vendor that competes in this space prices their database per GB. Therefore, the maximum ordinarily attainable footprint reduction should be roughly 50%. This is the number that we have applied to our cost calculations in this paper. Some customers will reduce their footprint slightly more, some a bit less, but we believe 50% is a reasonable assumption to use for footprint compression.
HANA’s pricing templates are not reliable and will not result in a correct SAP HANA price. They will result in the database being undersized. The customer will then need to go back to SAP to purchase more HANA GB licenses. However, if the customer had known the actual cost when buying the initial HANA licenses, it may well have changed their initial purchase decision.
Secondly, the price per GB declines as the size of the database increases. We do not have the information on whether SAP charges an incremental cost for the new HANA licenses or if the customer starts off buying the new HANA GB at “zero.”
However, once data has been migrated and the HANA database has been brought up, there is little in the way of options to move away at that point. The logical decision will be to purchase more incremental GB licenses of HANA. This is only one of the compound features around HANA that most customers have no idea about when they sign the contract.
In our estimate, many IT directors will be hiding HANA purchases’ actual results for years to come.
Who Sanctioned Deliberate Undersizing?
It should also be recognized that this is sanctioned from the very top of SAP. One of the primary proponents of the faulty and undersized footprint estimation of the SAP database has been none other than Hasso Plattner.
- HANA and S/4 (HANA) are tricky items to price. S/4 HANA has frequently been offered on promotion for free.
- However, S/4 HANA is not fully released as a suite. SAP is adding functionality on what is called a “birthing schedule.” Still, by the usual standard applied to applications, S/4 HANA Enterprise Management (EM) (that is, the entire suite) is simply not released. SAP was more honest about this in the past, but it has now changed its messaging to pretend that S/4 HANA EM is released. SAP has an on-premises version called 1151 and a cloud version called 1603.
Furthermore, notice the unusual numbering conventions that are not typical of SAP products.