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

Last Updated on May 11, 2022 by Shaun Snapp

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.

Lack of Financial Bias Notice: We have not 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. 

No vendor had any influence on this study, and the study received no funding or influence from any outside party.

Getting Clear on the Terminology

HANA is SAP’s database. The following applies:

  • HANA Cloud Platform (Now SAP Cloud), S/4HANA, and HANA Studio are not HANA. When reviewing non-HANA products with HANA in their name, the best policy is to pretend the word HANA has been removed.
  • S/4HANA has been artificially restricted so that it only runs on the HANA database. Although not part of the research, I have thoroughly analyzed the technical merits of SAP’s argument for why this is necessary and found all of SAP’s claims in this area to be without merit. SAP intends to use the artificial restriction of tying S/4HANA to HANA to push Oracle and other database vendors out of being used for S/4HANA. What will likely occur with S/4HANA being ported to non-SAP databases is covered in the Brightwork article Why SAP Will Have to Backtrack on S/4HANA. HANA and S/4HANA, more from a technical perspective, are included in many articles in the Brightwork blog dedicated to HANA and S/4HANA.
  • As S/4HANA uses a different database schema from ECC, S/4HANA is the first ERP system that will break all integrations and customizations that customers added to ECC. SAP has released information on these topics that indicates it prefers to obscure this issue as it would negatively impact S/4HANA purchases. SAP has instead performed a classic pivot and said that S/4HANA represents an “opportunity” to SAP customers to evaluate all current customizations and remove them. SAP is silent on integrations that will break and will need to be rewritten when S/4HANA is implemented.
  • Columnar or column-oriented database design is frequently explained as the reason for HANA’s performance. A column-oriented design means that the data is stored in columns rather than rows. A row-oriented design has been the dominant table design in databases since its invention. Column-oriented tables perform better for reading operations, which happens to be what is analytics.

The State of TCO Studies Generally

Before we get into our HANA TCO study, it is essential to generally take stock of TCO studies. We came to the conclusions we are about to describe several years ago when we first began to investigate the body of work of TCO studies.

We were quite surprised by our research to find that TCO studies generally is that they are of quite poor quality. And there are important reasons for this. Most software buyers and most vendors and implementing companies tend to focus on the acquisition cost. And there is not, outside of Brightwork, any IT media/research entity that focuses on calculating TCO for enterprise software. This is not to say that most IT media/research entities don’t pay lip service to the importance of TCO.

However, it is one thing to acknowledge something’s importance and something entirely different to put the work into performing its calculation.

  • TCO as a Positive Attribute: The critical distinction is that all analysts, vendors, and consulting companies like to talk about TCO in the abstract, but this does not have much meaning. One must be particularly suspicious when vendors with well-known high TCO applications talk about the importance of TCO.
  • Virtue Signaling: Being in favor of TCO is like saying you are in favor of the American flag or apple pie in favor of “goodness.” You can’t find anyone who opposes it in principle. But the devil is in the details. As long as nothing is quantified or the TCO studies are rigged, all vendors can say they have the lowest TCO.
  • A Foundational Rule of TCO: The first rule of any TCO analysis or any analysis is that the entity performing the analysis may not have a vested interest in its outcome. This essential and fundamental rule is violated routinely in the enterprise software space.

Vendors have a strong tendency and a strong bias as it helps them sell their software to underestimate the duration of their software implementation. Sales teams constantly pressure people that work in presales support to underestimate the implementation time projections to “get the deal.”

However, when we review actual implementations, they are much longer than the published implementation times. This came across very obviously in our Study into S/4HANA implementations.

The Research Method

The Brightwork Research & Analysis method was to reach out to as many of our contacts as possible to find case studies on HANA and combine this with our in-depth technical analysis of HANA’s design and capabilities.

These are the critical features of this research.

  1. The Necessity of Using Anonymous Sources: It is preferable to use actual customer names where S/4HANA implementations occurred. The problem is that this is not realistic, given the constraints of the market. SAP customers do not like publishing the details of their implementation outside of glossy generalizations of project success. The only time the problems on projects are published was when an implementation went so poorly that the customer decides to sue the implementing company or SAP. And in fact, settlements are sealed, so unless the case goes to trial, the paper trail ends abruptly. Outside of those occurrences, all SAP projects are presented as successes outwardly. As a long-time consultant and author, I have published many articles that described the reality of SAP functionality as implemented in companies. However, I would never have written what I covered if I had not anonymized the sources. Therefore, the only way to obtain any information on S/4HANA is to rely on anonymous sources for those sources that are original research.

Entities that release information about SAP projects are generally not interested in research or interested in releasing accurate information or following the scientific method. They are profit-seeking entities that are not bound by research rules. They have a straightforward agenda when they release information. For consulting companies and software vendors, they intend to increase sales of implementation services or software.

The Manipulation of TCO

After performing the background research into what is written in the field, we found the concept of TCO to have been manipulated by everyone from software vendors to IT analyst firms to meet predetermined objectives that were promotional. Many entities would prefer that companies did not know their TCO and present it as something dark and mysterious.

Some of the criticisms that have been directed at TCO almost seem directed towards influencing companies away from calculating TCO. The presentation is that TCO is not knowable. So many entities in the software field seem to be of the view that..

“TCO is very important, but it is not actually knowable.”

How something can be essential and a focus of discussion, but not quantifiable, is worthy of commentary all by itself.

TCO is not only possible to calculate (although it is always an estimate and must be described as having a range of accuracy or error); it is necessary and essential to perform to make effective IT decisions. It is, for example, far more attainable than software ROI.

While TCO analysis is undermined by multiple dimensions and numerous entities, it is also essential to get TCO right. This is because corporate purchases are more complex than consumer purchases, and the “price tag” on an item does not tell you a lot about the long-term total cost of that item. Enterprise software is an extreme example of this well-known purchasing reality. Many different researchers, including Brightwork Research & Analysis, have concluded that the software license cost will be roughly 10% of what the company will invest in its TCO application. Other areas include implementation costs, support costs, and maintenance costs.

Without an understanding of TCO, there is a powerful tendency to focus on acquisition costs.

Those who do not estimate TCO will be subject to overestimating the relatively minor acquisition costs and placing vendors with the highest TCOs on the same level as vendors with lower TCOs.

Forrester’s TCO Study

There has been one published TCO study on SAP HANA. It was sponsored by SAP and published by Forrester.

This study was not a severe study and was marred by the following problems.

  • * The study was created very early in HANA’s history — back when there were remarkably few go-lives. Forrester is at least evident in the study that all TCO estimates are projections. However, when it came to marketing the study, SAP left out this fact and made statements that Forrester has proven that HANA lowered TCO.
  • * Forrester used something called a HANA runtime license to calculate the software cost. However, Runtime licenses are temporary. They convert to a full use license when the system is used in a production setting. It is well known among those that sell HANA and other database vendors that the runtime license is just a way for SAP to get their foot in the door. Forrester’s explanation for why a runtime license was used made little sense. When combined with the fact that SAP paid for the study and the fact that HANA is the most expensive database that we track at Brightwork, the only conclusion we can come to is that Forrester used the runtime license specifically to lower the TCO of HANA artificially.
  • * Forrester proposed that hardware costs decrease with HANA. However, it is well known that HANA has the highest hardware specification of any database. This is because more of the database must be placed into memory, unlike other competing databases that move tables in and out of memory as needed. And secondly, SAP presents huge hardware specs to stack the deck in HANA’s favor. SAP has made quite a few proposals to compress data with HANA due to the column-oriented design. However, while SAP proposes over 90% compression, real data points that have come to Brightwork show compression of roughly 30 to 40%, which is incidentally similar to other column-oriented databases. But other database vendors also now offer better compression. So part of SAP’s compression numbers come from comparing against databases that they replace. That is older versions of competitors’ products.

The Forrester study is lengthy, and there are other serious problems with the study that we will not go into here as we covered them in the article How Accurate Was Forrester’s HANA TCO Study. Overall the study looks like paid for research, which was designed to reach a specific outcome.

Our conclusion is simple; the Forrester study is not credible and cannot be taken seriously.

Problems with HANA TCO Context HANA is being pitched to replace Oracle and IBM (primarily)

Most HANA purchases will not be for new applications that are not already functional. With this knowledge, SAP has repeatedly stated that HANA reduces both the implementation timeline and TCO. However, several things are indisputable concerning the timeline and TCO.

  1. One cannot replace an existing database faster than that database — as the database is already installed and operational.
  2. One cannot reduce the TCO of an existing database — a database with no implementation cost (as it has already been implemented) unless the maintenance costs are far lower. And so far, there is no evidence that HANA’s maintenance costs are more economical than Oracle or IBM.

This is a problem because when SAP markets when it markets based on inaccuracies.

The argument for lower TCO and implementation timelines only applies to new database implementations. However, new database implementations are a minority of HANA sales. In the vast majority of cases, SAP promotes HANA to replace and remove Oracle or IBM. This argues against SAP’s TCO claims for HANA.

The Brightwork TCO Method

TCO This is the overall output of the exercise. We have developed TCO calculations for over 50 different applications.

The use the following four main TCO categories, which are defined as:

  1. Software Cost
  2. Hardware Cost
  3. Implementation Cost
  4. Maintenance Cost

The TCO Cost Categories

Now that we have covered the general concepts surrounding the TCO methodology, what will follow is all of the individual cost categories that make up the final TCO.

Cost #1: License Costs

This is the vendor’s initial purchase price for an on-premises delivered solution or the ongoing monthly or yearly software cost if the software is purchased as a SaaS-delivered application, often called a subscription.

This is the method used for our other TCO estimates. However, it is not particularly relevant, at least at this time, for HANA, as the vast majority of HANA implementations are on-premises.

HANA is GB prices. The only database we know of that is quite expensive versus alternatives. For years SAP held a zero discount policy on HANA. But in 2015, this changed.

Here is one of the discount schemes offered by SAP in the past.

“SAP is offering the following promotion until the end of Q3/2015:

  • Existing SAP Business Suite customers have to procure the SAP HANA runtime license for SAP Business Suite (@15% HSAV = SAP HANA Software Application Value). They will get the SAP S/4HANA foundation promotion license at no additional cost.
  • Existing SAP Business Suite powered by SAP HANA customers with a valid SAP HANA limited runtime license for SAP Business Suite (LREA) are eligible for the SAP S/4HANA foundation promotion license without additional cost.
  • SAP is offering a 3rd Party Database credit. 50% of prior expenditure on databases bought with SAP licenses towards the cost of HANA Runtime license.”

These bullet points are less relevant because a runtime license is a non-production license. It is a way of getting customers into HANA inexpensively but sets them up for paying the far higher standard price as soon as they begin using it in production.

Cost #2: Hardware Costs

The hardware itself is a small component of the overall cost of all enterprise software.

This was not always the case – in fact, at one-time, computer hardware was so expensive it was not bought outright but rather was leased. But the phenomenal improvement in computing technology in the last four decades has shrunken the costs and increases the performance of hardware to a stark degree.

This graphic was cut off in 1986 because to continue the growth in speed until the present day would make the early increases imperceptible. 

However, the hardware contribution to TCO cannot be restricted to the costs of the actual hardware. Other costs relevant for hardware are its support – that is, the cost of IT professionals to keep the hardware running, upgrading the hardware, fixing it, etc.

Many individuals that specialize in hardware cost estimation use a factor of 20% to estimate the ongoing maintenance costs of hardware. However, the problem with this rule of thumb is that the maintenance costs for hardware are not proportional to the hardware costs. For instance, oversized hardware often requires less care and feeding than hardware that is undersized. This is because oversized software does not run into the constant constraints that under sizing requires. Undersized hardware not only increases the maintenance costs but increases the costs on the software side as well, as continuous adjustments are made to things like processing times and batch schedules to make up for limitations on the hardware side.

Costs #3: Implementation Costs Direct Estimation of Implementation Costs

Implementation costs are segmented into external costs and internal costs.

  1. External implementation costs are the consulting costs, which can come from the software vendor or a consulting company.
  2. Internal implementation costs are the costs that the company incurs during the implementation of using its internal resources. These are primarily the IT and business resources that are assigned to the project.
  3. Both external and internal implementation costs can be determined in several ways. We are calculating various implementation durations along with the allocation percentage and the cost of each resource. The billable rate for external resources and the fully-loaded costs for the internal resources is the most accurate method of determining implementation costs when one has first-hand experience implementing the software in question.
  4. However, as no person has implemented all the software for which a TCO would be desired, it is necessary to use multiple estimations on many occasions. The most common numerous estimations are based upon the license cost. Therefore, if the software cost is $1,000,000, and the consulting to license cost multiple is 2, then the estimated consulting cost is $2,000,000. Implementation multiples generally range from 1 to 4. Some applications for small businesses, like Quickbooks, can have a multiple that is less than 1, however true enterprise software, which is on-premises, will have a multiple higher than 1. The only way to get this lower is to use SaaS solutions. Various estimations cannot be accepted by software vendors but must be blending with experience in implementation. Many software vendors quote a 1:1 ratio between software costs and implementation costs. However, many software vendors are only considering the costs of their consulting and do not include internal resource costs for the implementing company. Generally, the best consulting value is from the consultants from the software vendor. As soon as a consulting company is involved, the costs of the implementation go up.

External Implementation Costs

Sometimes implementation costs are best determined by taking the following formula:

(Hourly Rate Per Implementation Consultant x the Percent of Time Assigned to the Project x The Implementation Duration) + Travel Costs

Module Implementation Consultant

This is the hourly rate for the module implementation consultant. This is the more junior resource on the project from the consulting company or the vendor.

The following formula calculates the cost of this resource:

(Hourly Rate * Percentage of Time on the Project) * Average of (Implementation Duration Low, Implementation Duration High) * 4.3(weeks per year) * 40(hrs)

Senior DB Consultant

This is the hourly rate for the more senior module implementation consultant. This is the more senior resource on the project from the consulting company or the vendor.
The following formula calculates the cost of this resource:

(Hourly Rate * Percentage of Time on the Project) * Average of (Implementation Duration Low, Implementation Duration High) * 4.3(weeks per year) * 40(hrs)Senior Manager/Partner This is the hourly rate for the more senior manager/partner.

This is the most senior resource on the project from the consulting company or the vendor. This resource will deal with project management issues, perform account management, acquire resources as needed, etc. These are not full-time resources but tend to either manage multiple projects (if they are from the vendor) or to manage the overall program (of which the module which is being calculated here) is just one part.

There is a separate line item for the percentage that each of these resources is on the project. Changing either the hourly rate or the percentage, they are on the project adjusts the consulting costs. I won’t list the explanations for each of the consulting line items’ duration, as they should be self-explanatory.

The following formula calculates the cost of this resource:

(Hourly Rate * Percentage of Time on the Project) * Average of (Implementation Duration Low, Implementation Duration High) * 4.3(weeks per month) * 40(hrs)

Internal Implementation Costs

The next area to estimate is the internal implementation costs.

Total Client Resource Costs for the Implementation

This is the total cost of staffing the client resources for the project. Often, client resources assign part of their time to the project while retaining most of their other duties. More applications are part of the implementation. The more likely internal resources will be 100% allocated to the project. The formula we use for the total client resource costs is as follows:

  • The Total Client Resource Costs = (Implementation Duration in Weeks * The Opportunity Cost Per Week) * The Percent of the Average Week the Employee is assigned to the Project Given the following assumptions:
  • The Implementation Duration in Weeks = (Average of the Duration in Months * 4.3)
  • The Opportunity Cost Per Week = (The Number of Employees on the Project * The Hours Per Week * The Number of Weeks * The Fully Loaded Hourly Rate the Employee Costs the Company)
  • The Percent of the Average Week the Employee is Assigned to the Project

Percent of Total Costs (Implementation Costs)

This is the total cost of staffing the client resources for the project. Often, client resources assign part of their time to the project while retaining most of their other duties. More applications are part of the implementation. The more likely internal resources will be 100% allocated to the project. The formula we use for the total client resource costs is as follows:

The Total Client Resource Costs = (Implementation Duration in Weeks * The Opportunity Cost Per Week) * The Percent of the Average Week the Employee is assigned to the Project

Given the following assumptions: Given the following assumptions:

  • The Implementation Duration in Weeks = (Average of the Duration in Months * 4.3)
  • The Opportunity Cost Per Week = (The Number of Employees on the Project * The Hours Per Week * The Number of Weeks * The Fully Loaded Hourly Rate the Employee Costs the Company)
  • The Percent of the Average Week the Employee is Assigned to the Project

Percent of Total Costs (Implementation Costs) This adds all the implementation costs divides by the total costs.

The Percent Each Resource is Assigned to the Project

Often, client resources assign part of their time to the project while retaining most of their other duties. More applications are part of the implementation. The more likely internal resources will be 100% allocated to the project. However, this is only a TCO for the implementation of one application.

Implementation Duration

This is the measurement from the beginning to the end of the implementation. The duration of a project cannot be predicted with much reliability to the month. Companies that attempt to meet the deadlines that they predict before the project begins often end up with faux go-lives, where the software is not ready, and work as to continue intensively after the go-live because they went live too early.

Additionally, different clients have different levels of complexity and various functionality of the application or database. Some clients may leverage older and more proven functionality, while others may choose to activate newer and less proven functionality. Some companies want consulting companies that don’t know the software very well can’t document the solution, etc. There are so many factors that go into the implementation duration – however, the most crucial factor is the database’s quality and maturity and its implementation ability.

  • We assign an implement-ability score to every application that we review. This is important because so many companies declare – implicitly that all software that they add to the software selection exercise is equally implementable. They don’t say this, of course, but it is assumed as they do not differentiate based on this factor. However, this is a false assumption. Some software is designed to be sold more than it is intended to be implemented.

Cost #4: Maintenance Costs

These are the costs of keeping the database or application up and running post-go-live. Maintenance costs are some of the most underestimated enterprise software costs. These costs are composed of both the yearly support fee and the internal labor costs of providing support.

Internal Maintenance Costs

This is the allocation of internal resources to maintain the solution for the lifetime of the company’s application. The following formula calculates this.

Internal Maintenance Cost = The Fully Loaded Resource Cost Per Year * The Average Allocation of Time to Support the Application * The Number of Years the Application is Used

Our TCO Estimate

Our TCO estimate for HANA is a multiple or fraction of the TCO of competing solutions such as Oracle 12c and IBM Blu. There was no attempt to differentiate Oracle’s costs versus IBM, but rather the TCO of these databases was averaged.

This table has supporting explanations for each cost category.

HANA TCO and Cost Categories

Categorizing TCO cost categories.
Cost DescriptionCost CategoryEstimated Multiple or FractionTraditional Cost as a % of Total Cost
DC Impacts, Significant Additional Power, Cooling, Space, + Any Drag Along ("per core licenses" for backup/recovery, monitoring, scheduling, etc)Hardware2
Inefficient use of Non-Commodity H/W Resources - Cores, GB Ram, lots of SAP TDI based storage (X5 for Logs (x1)Hardware3
Non-Commodity Hardware/Appliance Costs, Refresh Cycles (Very Spiky, Peaky Utilization)Hardware3
Total Hardware Multiple2.57%
Complexity of "Multiple" Database Building Blocks "Commodity" Hardware/Appliance Costs, Refresh Cycles (Very Spiky, Peaky Utilization)Maintenance1.8
Frequency of SAP HANA Database Patches, Version UpgradesMaintenance2.5
Average Implementation Multiple2.1560%
Complexity of Getting the Sizing Right (in particular, if user or data growth rates are unknown vs. any prior pattern)Implementation3
Required Data Archiving, House Keeping, Clean UpImplementation3
General HANA Implementation CostsImplementation2.5
Changed Table / Data Structures + need to check, confirm availability of add-on'sImplementation2.5
Average Implementation Multiple2.7520%
Purchase PriceSoftware1.7
Average Software Multiple or Fraction1.713%
  • 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.


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/)