A Study into SAP HANA’s TCO (Complete) (2017)

Executive Summary

• Our HANA TCO study is a complete accounting of TCO without being funded by SAP.
• We provide a TCO estimate based upon actual real HANA case studies.

*The introduction is in the free portion of the research and will not be repeated here. 

Video Introduction: A Study into SAP HANA’s TCO (Complete) (2017)

Text Introduction (Skip if You Watched the Video)

This is the only independent TCO analysis of HANA that exists. SAP has done whatever it can to either rig TCO studies by paying for them, or by trying to get SAP customers to focus on supposed better value due to improve performance. This is always the case when the vendor funds any TCO study. You will learn about the Brightwork method of TCO, and how HANA performed versus another similar database in terms of proportions.

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. 

• New Implementation Multiple: The rolls up to a 2.24 multiple for HANA versus competing for database offerings when the database is new.
• Replacement Multiple: However, the multiple rises to 2.41 when HANA is replacing an already installed database. The reason for this is the current database that is installed being kept running. In our estimates, for between 1 year to 1.5 years while HANA is being implemented. We took an average of 1.25 years as to how long HANA would take to implement. Of course, a more specific number could be developed for a particular company that is implementing HANA, but we needed an average.

This issue of replacement is a common one concerning sidecars. In principle, the sidecar is supposed to go away and replace the core product eventually. But with S/4HANA, sidecars have a way of being around much longer than expected. This is true of most SAP applications implemented as a sidecar but is particularly true of S/4AHANA sidecars due to the significant maturity issues of S/4HANA up to this point.

Underestimating the Cost of HANA

The estimate you see above is not inclusive of the fact that SAP requires multiple HANA licenses. In many situations, SAP requires customers to purchase various HANA licenses. For example, we have SAP observations requiring customers to buy a second copy of HANA, where data is replicated from one copy of HANA before it can be exported to a data warehouse. This is covered in the article The HANA Police and Indirect Access. But this depends on the specific situation, therefore making including in a TCO calculation difficult. We are confident that our estimate understates the actual HANA TCO multiple versus competing offerings for these reasons and others.

Specific Cost Categories and Multiples Explained

In this section, we will explain the logic of the cost difference per cost category.

Something that must be included in any TCO of HANA is that SAP bundles HANA with other database products, notably SAP ASE (formerly Sybase ASE), a row-oriented database. SAP pitches this is a value bundle, but ASE is necessary for things like PI/PO integration. SAP IQ (formerly Sybase IQ) for archival. To bring the price down of HANA to a reasonable level, extensive archival is required, for which SAP recommends SAP IQ. And this does not include the components below HANA or on which HANA depends on its normal operating functions.

The further result of this is that companies that use HANA end up using far more assistive databases and far more technical supporting components than competing database offerings. This has the most significant impact on implementation and maintenance.

Purchase Price

HANA is a premium-priced database, but this depends upon sizing.

The problem with determining HANA’s cost is that the information provided by SAP regarding sizing is purposefully designed to get companies to undersize HANA, making it seem as if the cost of HANA will be lower than it turns out to be. This is covered in the following link.

Changed Table / Data Structures + need to check, confirm availability of add-on’s

A general issue for all applications, not only S/4HANA. HANA changes the tables of applications. This means that there is significant overhead in managing the new data model.

General HANA Implementation Costs

HANA has several reasons for being more expensive to implement those competing databases.

1. HANA is a less mature database than competing offerings.
2. HANA takes longer to implement than competing offerings.
3. HANA has more complexity than competing offerings.
4. There are fewer HANA available experienced resources than competing offerings.
5. HANA resources are some of the most expensive database resources on the market.

Required Data Archiving, House Keeping, Clean Up

• HANA has high archival requirements because HANA is priced per GB and has a high cost. Therefore, the customers need to archive to bring down the price of HANA.
• This extensive archiving is not necessary with other competing databases as they are not priced per GB. SAP has made a great deal of noise about how well HANA compresses. These compression estimates are highly exaggerated. However, the database’s size (and the need for extreme archiving) is only an issue if the database is priced by volume.
• Overall, this is an issue because SAP is setting archiving policy at HANA customers — and merely because of how SAP decided to price HANA.

The Complexity of Getting the Sizing Right (in particular, if user or data growth rates are unknown vs. any prior pattern)

Sizing a significant consideration with HANA that is not anywhere near to an issue with competing offerings. It is tough to size. Furthermore, SAP provides inaccurate information about HANA sizing (to get customers to undersize HANA to underestimate the cost, and they then go with HANA). For this reason, it is not possible to size HANA by using SAP-provided information. That is because of how HANA is priced and the sales incentives of SAP. They have a conflict of interest in providing accurate sizing information. SAP intends to get HANA into the account. This, of course, results in a HANA sale. Still, after HANA has been purchased, there is a very high likelihood that the customer will come back for more HANA licenses (to make it right) rather than writing off its investment into HANA.

Frequency of SAP HANA Database Patches, Version Upgrades

HANA is continually being patched and changed because HANA is a far less mature database than competing offerings. HANA has so much instability that SAP has come up with talking points that aim to reframe the narrative.

1. SAP calls frequent database patches and upgrades “innovation.” They use this term even though these developments are often required to bring HANA up to par with competing databases.
2. SAP introduced a storyline about a new version of HANA, called HANA 2, that was primarily around distracting customers from the fact that there were compatibility issues between some versions of “HANA 1” and HANA 2.

A database that requires content patching, many new versions, compatibility issues, etc.. translates into higher costs than competing database offerings.

The Complexity of “Multiple” Database Building Blocks

HANA relies upon more components than any of the competing offerings. All of these components must be updated and managed.

This takes more effort to maintain for HANA. And this translates into increased costs.

Non-Commodity Hardware/Appliance Costs, Refresh Cycles (Very Spiky, Peaky Utilization)

HANA uses more expensive hardware than competing database alternatives. SAP designed HANA to be entirely loaded into memory, which means a higher memory cost.

Inefficient use of Non-Commodity H/W Resources – Cores, GB Ram, lots of SAP TDI based storage (X5 for Logs (x1)

HANA has far more expensive hardware requirements than the competing database offerings. One reason is the considerably higher memory requirements for HANA, as the entire database must be loaded into memory.

A second reason is that HANA cannot effectively use commodity hardware. This translates into higher hardware costs.

DC Impacts, Significant Additional Power, Cooling, Space, + Any Drag Along (“per core licenses” for backup/recovery, monitoring, scheduling, etc.)

This extra overhead in the database infrastructure areas results in more costs.

The Issue With SAP’s Statements Regarding HANA’s Speed of Implementation

But that is just a beginning point. Even if we start from two new systems being compared, HANA will take longer to implement because it is more sophisticated and less tested than previous SAP products. Aside from the speed of the implementation question, it also means higher risk. Anyone who thinks that new products implement faster than older products with many implementations do not work in software. All of this is clear from understanding HANA’s state, but it is also born out in the data points coming in from the field.

Now, there may be a higher payoff, although that contention is not proven in any of the articles on HANA. But the risk and project duration should account for the relative newness of HANA.

The one case where this may not be the case is with a BI/BW implementation. When BW is implemented on top of HANA, it means time is saved through less time spent configuring the Data Workbench. But that is only for a fresh installation. Companies that already configured the data structures will just mean there is now less of a need for those structures. And of course, HANA is a pure analytics database design, so it will always work best for analytics applications like BW.

However, no other SAP application should be expected to receive this implementation benefit. The reasons why diverge from this paper’s research purpose but have been very well researched by Brightwork Research & Analysis, and we are very confident in this aspect.

The HANA TCO Multiple

At Brightwork, we have many TCO calculators. However, for this estimate, considering that many SAP customers are considering moving to HANA in part based upon SAP statements about HANA’s lower TCO, it made the most sense to develop a multiple or percentage in terms of how HANA would compare to Oracle 12c and IBM BLU.

MS SQL Server also runs SAP applications. However, HANA is not targeted to MS SQL Server as MS SQL Server tends to target the lower budget portion of the relational database market. SAP does not mention MS SQL Server, but MQ SQL Server is in a very different cost category and tends to be used by smaller SAP customers.

The Issue of “Dual HANA” Instances

This TCO study was performed by comparing one HANA instance to one AnyDB instance. However, because of indirect access rules applied by SAP, any single application instance of HANA requires a second instance for replication before the data can be extracted to a database. This is the “dual HANA” instance issue, and it aggressively increases the TCO of using HANA for apparent reasons. The dual HANA license issue is covered in the article The HANA Police and Indirect Access Charges.

References

The Expense of HANA
[Which is Faster HANA or Oracle 12C? – Brightwork | SAP HANA](https://www.brightworkresearch.com/saphana/2016/04/09/which-is-faster-hana-or-oracle-12c/)

Speed of HANA Implementation
[When Articles Exaggerate SAP HANA’s Benefits – Brightwork | SAP HANA](https://www.brightworkresearch.com/saphana/2016/09/02/articles-exaggerate-sap-hanas-benefits/)

The Forrester TCO Study
[How Accurate was Forrester’s TCO Study for SAP HANA? – Brightwork | SAP HANA](https://www.brightworkresearch.com/saphana/2017/07/09/how-accurate-was-forresters-tco-study-for-sap-hana/)

Understanding the TCO of HANA
[How to Understand the TCO of SAP S/4HANA – Brightwork | SAP HANA](https://www.brightworkresearch.com/saphana/2017/02/25/understand-tco-sap-s4hana/)