- SAP has proposed that HANA is a perfect fit for ERP. However, the evidence is that there is no advantage of HANA for ERP systems but there are many disadvantages.
- In this article, we discuss where our data comes from related to HANA’s mismatch.
Introduction to S/4HANA’s Mismatch with ERP Systems
SAP restricted S/4HANA to just the HANA database, breaking with decades of having their ERP system be database independent and creating great inconvenience and higher cost for customers. You will learn whether HANA is actually a fit for ERP systems.
A Major Advantage for Using with ERP Systems?
Column based databases like HANA are not an advantage when the database in question is supporting an application like an ERP system, or any other transaction processing system.
This is because transaction-processing systems tend to access all of the fields in a row. However, when the application in question is analytical, technically known as OLAP, then the database design/table configuration is a disadvantage because the typical query only accesses a few of the fields or columns in a table.
This is explained well in this paper from Oracle on the topic of their 12c product, which is another in-memory database.
“Oracle Database has traditionally stored data in a row format. In a row format database, each new transaction or record stored in the database is represented as a new row in a table. That row is made up of multiple columns, with each column representing a different attribute about that record. A row format is ideal for online transaction systems, as it allows quick access to all of the columns in a record since all of the data for a given record are kept together in-memory and on-storage. A column format database stores each of the attributes about a transaction or record in a separate column structure. A column format is ideal for analytics, as it allows for faster data retrieval when only a few columns are selected but the query accesses a large portion of the data set. But what happens when a DML operation (insert, update or delete) occurs on each format? A row format is incredibly efficient for processing DML as it manipulates an entire record in one operation i.e. insert a row, update a row or delete a row. A column format is not so efficient at processing row-wise DML: In order to insert or delete a single record in a column format all of the columnar structures in the table must be changed.”
This points out that for inserts, deletes or updates — which a transactions processing system — like an ERP system — does all the time. The column based table is slower than the row based — or what is known as the relational database (although using the term relational to differentiate row based on column-based databases is not technically accurate as they are both relational databases — the distinction is the format and type of tables used)
ERP on HANA Processing Problems
Getting back to the main point of this section, ERP on HANA will not speed the processing of ERP systems for most of what ERP systems do. This is Oracle’s point in this quotation from John Soat.
“SAP has not published a single benchmark result for any of its transaction processing applications running on HANA.”
I agree with John Soat, in that there is a very reasonable explanation for why SAP does not publish this…because the benchmarks are not impressive.
Where is Our Data Coming From?
This information that is provided below is from multiple sources. Some are from actual client sources. None of the sources is interested in being identified so they won’t be.
Furthermore, we have more information regarding details than we will provide in this or other articles. The reason for this is related to source protection. The way that we can provide this type of information is that the sources aren’t identified or can’t be traced by SAP through the detail that we provide.
Regarding our credibility, the reader can review our SAP prediction accuracy list.
Brightwork is not paid by SAP or any other database vendor (or any non-database vendor for that matter.) We have no incentive to push one database above another. We don’t own stock in any database vendor or any other financial tie. And furthermore, our analysis in this area should not be seen as a general endorsement for any non-SAP vendor.
This differentiates us from Forrester and Gartner who are paid by database vendors. Forrester sometimes declares these payments, Gartner never does.
The Problem Between HANA and ERP
The data we have analyzed show the following performance features of HANA.
- Simple queries for analytics run quickly, but not any more rapidly than competing databases.
- Complex queries for analytics run more quickly than a row-oriented database, but not as fast as competing databases.
- Transaction processing (things like posting goods issue, decrementing inventory, etc..) runs significantly slower on HANA than on row-oriented databases. That is even when accounting for HANA’s better hardware.
- Processor intensive operations run significantly slower on HANA than on row-oriented databases. Again, this is even when accounting for HANA’s better hardware. An example of a processor intensive activity is MRP. See our article How to Interpret HANA’s Problems with MRP.
See our other article which questions Why Do Companies Continue to Run MRP from ERP systems.
The problem with this information on HANA’s performance profile? ERP systems primary activities are number 3 & 4, transaction processing and processor intensive operations. Not 1 & 2. This means the overall system will run slower if the transaction processing and processor intensive activities are disadvantaged.
This is a severe problem for HANA’s value for ERP systems. The things HANA does well, are not related to what ERP primarily does.
Transaction Processing Problems
HANA has had continual problems in what should be the primary focus of any database that supports an ERP system, transaction processing. Transaction processing is the most important thing that any ERP system does and SAP’s marketing around the importance of analytics has not changed the primary processing type of ERP.
On April 10, 2018 Lenovo published the technical paper, Lenovo SAP S/4HANA Scale out – Cycle 1.
This paper included a number of inaccuracies, which should not be surprising as Lenovo is an SAP partner and has a series of products they are trying to sell that are connected to HANA.
Notice the hardware specification below from the Lenovo paper.
The HANA box has a higher hardware specification, but it is hidden with the AnyDB/ECC server configuration not called out.
Natural questions that arise.
- Where is the hardware configuration listing on the AnyDB/ECC server?
- How is the reader to know if the hardware is comparable? As we have pointed out in the article How Much of Performance is HANA?, many improvements that have been seen from HANA are due to the entity testing HANA against older hardware and previous versions of AnyDB.
Either Lenovo does not know how to list the specifications of the box, or more likely, Lenovo is excluding the AnyDB/ECC listings to obscure the fact that the hardware is not remotely comparable. How can this go unnoticed by those that read these studies?
Now look at the transaction processing.
Why are the exact comparisons redacted? Secondly, how is anyone to know how much of the improved transactions are from the HANA boxes higher hardware specification? And SAP promised massive improvements in performance across the board, so why are any of the transactions negative?
The redaction is quite odd, as there is no reasonable explanation why this should be.
Analytics on S/4HANA?
Now one could construct a scenario where a bunch of analytics is performed in ECC/S/4HANA. SAP has stated this as their vision. The concept is that all analytics would be performed inside the ERP system. Let us go back to the Lenovo study.
This is compared against an older version of most likely either Oracle or DB2, which did not have multimodel capability (that is column-oriented with row-oriented). However, why are any of the analytic scores slower than the older database versions?
- Observations from the field show HANA underperforming all of the competitor databases, even SQL Server even in analytic workloads. This level of improvement, up to 2846% shows the hardware difference between the ECC box and the HANA box.
- Once again we have redacted actual scores. What is being hidden here?
Columnar databases are a disadvantage for ERP systems or any transactional processing system. That is what makes SAP’s statements about SAP entirely inaccurate. Secondly, in any ERP system, data can be aggregated and updated to just a few hundred tables. These tables can be made columnar — while the rest of the database stays as row-based (or as is known as relational). This is the design deployed by Oracle 12C, and it calls into big issue the design used by ERP on HANA. Details on this plan are available in this article
These tables can be made columnar — while the rest of the database stays as row-based (or as is known as relational). This is the design deployed by Oracle 12c, and it calls into big issue the design used by SAP for ERP on HANA. Details on this plan are available in this article Which is Faster, HANA or Oracle 12C?
Thus there is no way to see HANA performance profile as anything but a net loss in performance for ERP.
This means that the migrations of ECC to HANA as well as implementations of S/4HANA, what there are of them, resulting in performance degradation for the companies that implemented them.
Furthermore, SAP customers paid a very high premium for a reduction in performance.
Search Our Other HANA Content
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model