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

Executive Summary

  • It is necessary to get clear on HANA terminology.
  • SAP paid Forrester to manipulate the TCO with HANA.
  • Our HANA TCO study is a complete accounting of TCO withing 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. 

Getting Clear on the Terminology

HANA is SAP’s database. The following apply:

  • HANA Cloud Platform (Now SAP Cloud), S/4HANA, HANA Studio are not HANA. When reviewing non-HANA products that have HANA in their name, the best policy is to simply pretend as if 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 covered in a number 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 has said that S/4HANA represents an “opportunity” to SAP customers to evaluate all current customizations and to remove them. SAP is silent on the topic of 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 simply means that the data is stored in columns, rather than rows. A row-oriented design has been the dominant table design in databases since their invention. Column-oriented tables perform better for read operations, which happens to be what is analytics.

The State of TCO Studies Generally

Before we get into our HANA TCO study, it is important to take stock of TCO studies generally. 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, as well as 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 important 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 actually 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 in fact any analysis is that the entity performing the analysis may not have a vested interest in its outcome. This basic and fundamental rule is violated routinely in the enterprise software space.

Vendors have a strong tendency to underestimate the duration of the implementation of their software. 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 to 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 be able 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 is 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 quite 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 been able to write 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 who are not bound by research rules. They have a straightforward agenda when they release information. For consulting companies and software vendors, their intent is 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 in order to meet predetermined objectives which were promotional in nature. It seems that many entities that would prefer that companies not actually know their TCO and to 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 important 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 important to perform in order to make effective IT decisions. It is for example, far more attainable than software ROI.

While TCO analysis is undermined from multiple dimensions and by multiple entities it is also most important to get TCO right, and 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 what the long-term total cost of that item will be.Enterprise software is the extreme example of this well-known purchasing reality. In fact, many different researchers, including Brightwork Research & Analysis have concluded that the software license cost will end up being roughly 10% of what the company will invest in the application or its TCO. 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 that do not estimate TCO will be subject to overestimating the relatively minor acquisition costs, and toward 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 serious study and was marred by the following problems.

  • * The study was created very early in HANA’s history — back when there were extremely few go-lives. Forrester is at least clear 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 by 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 artificially lower the TCO of HANA.
  • * 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 very large hardware specs to stack the deck in HANA’s favor. SAP has made quite a few proposals that data can be compressed with HANA due to the column-oriented design. However, while SAP proposes over 90% compression, real data points that have come to Brightwork show a compression of roughly 30 to 40% — which incidentally is a similar compression ratio 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. Yet with this knowledge, SAP has repeatedly stated that HANA reduces both implementation timeline and TCO. However, several things are indisputable with respect to 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 that has 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 lower than Oracle or IBM.

This is a problem because when SAP markets when it markets what are impossibilities.

The argument for lower TCO and implementation timelines only applies for 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.

License Costs

This is the initial purchase price from the vendor 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 the only database we know of that is priced by GB, and it 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) and 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.

Hardware Costs

The hardware itself is a small component of the overall cost of all of 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 which are 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 costs of the hardware. For instance, hardware that is oversized 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. In fact, undersized hardware not only increases the maintenance costs but increases the costs on the software side as well, as successive adjustments are made to things like processing times and batch schedules in order to make up for limitations on the hardware side.

Implementation Costs Direct Estimation of Implementation Costs

Implementation costs are segmented into external costs and internal costs.

  1. External implementation costs are the costs of consulting which can come from the software vendor or from a consulting company.
  2. Internal implementation costs are the costs that the company incurs during the implementation from 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 several ways. 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 cost 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 on many occasions to use multiple estimations. The most common multiple estimations is based upon the license cost. Therefore, if the cost of the software 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 business, like Quickbooks, can actually 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. Multiple estimations cannot be simply accepted from 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 from the vendor.

The cost of this resource is calculated by the following formula:

(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 from the vendor.
The cost of this resource is calculated by the following formula:

(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 from 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 – which adjusts the consulting costs. I won’t list the explanations for the duration of each of the consulting line items, as they should be self-explanatory.

The cost of this resource is calculated by the following formula:

(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. Most often client resources assign part of their time to the project while retaining most of their other duties. The more applications are part of the implementation, the more likely it is that 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. Most often client resources assign part of their time to the project, while retaining most of their other duties. The more applications are part of the implementation, the more likely it is that 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 simply adds all the implementation costs divides by the total costs.

The Percent Each Resource is Assigned to the Project

Most often client resources assign part of their time to the project while retaining most of their other duties. The more applications are part of the implementation, the more likely it is that 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 their deadlines that they predict before the project begins, often end up with faux go-lives, where the software is not really 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 in different areas of 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 choose consulting companies that don’t know the software very well, or can’t document the solution, etc.. There are so many factors that go into the implementation duration – however; the most important factor is the quality and maturity of the database itself, and specifically its implement ability.

  • We assign an implement-ability score to every application that we review. This is important, because so many companies simply declare – implicitly, that all software that they add to the software selection exercise is equally implementable. They don’t declare 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 designed to be implemented.

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 as well as the internal labor costs of providing support.

Internal Maintenance Costs

This is the allocation of internal resources to maintaining the solution for the lifetime of the application in the company. This is calculated by the following formula.

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

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

This table has supporting explanations for each cost category.

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

This issues of replacement is a common one with respect to sidecars. In principle, the sidecar is supposed to eventually go away and replace the core product. 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 multiple HANA licenses. For example, we have observations of SAP requiring customers to purchase 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, and therefore making including in a TCO calculation difficult. For these reasons and others, we are confident that our estimate understates the actual HANA TCO multiple versus competing offerings.

Specific Cost Categories and Multiples Explained

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

Something which must be included in any TCO of HANA is that SAP bundles HANA with other database products, notably SAP ASE (formerly Sybase ASE), which is a row-oriented database. SAP pitches this is a value bundle, but in fact, 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 fare more assistive databases as well as far more technical supporting components than competing database offerings. This has the largest impact on implementation and on 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 to managing the new data model.

General HANA Implementation Costs

HANA has a number of 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 in order 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 size of the database (and the need for extreme archiving) is only an issue if the database is priced by volume.
  • Overall, this is an issue because it means that SAP is setting archiving policy at HANA customers — and merely because of how SAP decided to price HANA.

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

Sizing a major consideration with HANA that is not anywhere near to an issue with competing offerings. It is extremely difficult to size. Furthermore, SAP provides inaccurate information about HANA sizing (to get customers to undersize HANA so that they 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. The intent of SAP is to get HANA into the account. This, of course, results in a HANA sale, but 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 constantly 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 simply 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, frequent new versions, compatibility issues, etc.. translates into higher costs than competing database offerings.

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 far 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 simply 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 implementation question, it also means higher risk. Anyone who thinks that new products implement faster than older products with many implementations behind them does 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 saved through less time spent configuring the Data Workbench. But that is only for a fresh installation. For companies that already configured the data structures, it will just mean there is now less of a need for those structures. And of course, HANA is as 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 the research purpose of this paper, but have been very well researched by Brightwork Research & Analysis and we are very confident on 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 be targeted towards 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 at smaller SAP customers.

The Issue of “Dual HANA” Instances

This TCO study was performed 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, or obvious reasons. The dual HANA license issue is covered in the article The HANA Police and Indirect Access Charges.

Software Selection

  • Want Help with Software Selection for your Business?

    It is difficult for most companies to perform software selection without outside advice. It is impossible to obtain honest software selection support from consulting companies. We offer expert and unbiased remote software selection support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

References

The Expense of HANA
[Which is Faster HANA or Oracle 12C? – Brightwork | SAP HANA](http://www.scmfocus.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](http://www.scmfocus.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](http://www.scmfocus.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](http://www.scmfocus.com/saphana/2017/02/25/understand-tco-sap-s4hana/)

Table of Contents (Click Any Link to Jump to That Section)