- Oracle presents an excellent case for not following SAP on implementing S/4HANA.
- We explain the logic for pressuring SAP on creating S/4AnyDB.
SAP aggressively pushed for companies to implement S/4HANA. However, S/4HANA has a massive liability in its data model, which requires extensive code remediation.
See our references for this article and related articles at this link.
Code Remediation for S/4HANA
As S/4HANA has a radically different data model, with 10,000 tables becoming 3,000 tables. It means that every adapter or customization that exists an ECC customer will need to be rewritten. This is a major effort, and the problem is that it does not come with a corresponding benefit because HANA underperforms competing databases. The database design of HANA is a poor fit for ERP, as we cover in the article Mismatch Between HANA and S/4HANA and ECC. SAP refused to benchmark its database against competing databases and created an entirely new benchmark that is not a good fit for how S/4HANA or any ERP systems used, as we cover in the article How to Understand the Issues with BW EML Benchmarks.
The upshot of it is that SAP is imposing a highly expensive and high overhead database with a significant remediation overhead (in addition to the overall high cost of HANA) onto customers.
SAP and the SAP consulting companies have been minimizing is the code remediation effort for S/4HANA so they can lull customers into a false sense of the work effort involved increasing their ability to sell customers on S/4HANA. At one recent account, there was not a single mention of the code remediation to the customer by either SAP or Deloitte.
We disagree with the major SAP consulting firms; our recommendation has been to pull forward the code remediation analysis to before the project begin date. And to ignore all advice come from either SAP or SAP consulting firms on this topic as we cover in the article Why it is Important to Pull Forward S/4HANA Code Remediation.
Oracle’s Proposal on its Data Model for SAP
in August of 2019, Oracle published a document called Oracle for SAP Database Update.
The new column format is a pure in-memory format. Tables are stored on disk using Oracle’s existing row-based formats. Since tables as such are never stored in columnar format on disk, there are no additional storage costs or storage synchronization issues. Nor is there a need to modify the database. Oracle Database 12c In-Memory can be implemented without a database migration or a table reorganization.
As a result, the new Oracle Database 12c In-Memory feature is fully compatible with existing standard or optional database features such as table and index compression, table encryption, and table partitioning. It is also compatible with the scale-out architecture provided by Real Application Clusters (RAC) and with all existing high availability technologies (such as Data Guard).
This following anonymous provides more details.
In Oracle DB, the tables are always stored in row format and only exist in column format in memory only for those tables that are needed for analytics. Totally transparent to the application codes.
In fact the coding can be even simpler as the coder does not need to worry whether a table is row or column based, the DB engine will decide based on the query to use the row format or the column format.
The Logic of Using HANA for Other Applications
HANA is a particularly poor value for any ERP system, and it is better suited to an entire analytics application, which is why the most comment implementation of HANA up to this point has been for BW. However, while HANA is far better suited for BW than for S/4HANA, it is still not competitive with AnyDB based on cost, performance, or maintenance overhead. And this quote from Oracle illustrates the misleading descriptions that SAP uses to trick people into thinking they must use HANA to gain specific capabilities.
From a business or user perspective what looks like one single “cube”, is actually a set of multiple tables, and the relationships between them can be described as a multi-level hierarchy. But this complex structure, which requires many joins when a query or a report is executed, slows down in-memory databases considerably. Therefore, SAP designed a new, simpler data model for SAP BW on HANA and consequently called it HANA-Optimized InfoCubes.
This also means that much of the benefit of the BW application is reduced because the BW Data Workbench was where the star schemas were created. Once HANA was introduced and by extension, other databases that have columnar capabilities, the work done in BW significantly is reduced, which reduces the reason for using BW in the first place. This observation is left out of any SAP or consulting firm commentary on this topic.
However, this new data model is not only optimized for HANA. It is optimized for in-memory computing in general. Therefore SAP on Oracle users who have activated Oracle Database In-Memory can implement it as well, the only difference being the name (Flat InfoCubes or simply Flat Cubes). A less famous, yet important optimization is Table Declustering. A cluster table stores a complete (logical) record in one single (physical) table column. Such a complex value can be interpreted by the SAP Application Server, but not by a database server – which means that code pushdown is not possible, if a cluster table is involved. Therefore SAP now supports Table Declustering, for HANA as well as for the Oracle Database.
Naming flat infocubes “HANA optimized,” according to Oracle, is deceptive (and I agree). They are simply infocubes that are not based upon star schemas. But when a customer reads, they are “HANA optimized” the impression is that one needs to have HANA to leverage them.
The Problem with S/4HANA’s Data Model
In the book Software Wasteland, Dave McComb makes the following statement about data models developed by application vendors.
All enterprise applications have data models. Many of them are documented and up to date. Data models come with packaged software, and often these models are either intentionally or unintentionally hidden from the data consumer. Even hidden though, their presence is felt through the myriad screens and reports they create. These models are the antithesis of elegant. We routinely see data models with thousands of tables and tens of thousands of columns, to solve simple problems. Most large enterprises have hundreds of thousands of these data models.
S/4HANA is an example of an application that imposes a data model that is inefficient for the majority of what S/4HANA does as a system, which is transaction processing. SAP jumped the gun, and following Hasso Plattner, presumed they had knowledge in database modeling that they did not have. What is a good sign that a person is faking his understanding of a topic? Well, if a person has an honorary degree, and tries to pass it off as a real Ph.D., this is a good indicator as we cover in the article Does Hasso Plattner Have a Ph.D.?
For the same reason, if you find a medical doctor who states they have an MD, and they don’t, then it is a good idea to skip the medical advice of this person also.
S/4HANA’s data model is a problem and will impose not only a performance issue but significant technical debt on those that migrate to S/4HANA.
What is even more amazing is that for years SAP sold this ineffective data model change under the marketing construct of data simplification, as we cover in the article Does HANA Have a Simplified Data Model?
That is, SAP has presented its neophyte data model, which overly relies on columnar tables, and which has had to have row-oriented tables added to its initial design.
It is important to remember that when HANA was first introduced, it was introduced as a 100% column-oriented table database. This is explained in the following quotation from John Appleby.
With ERP on HANA, we, of course, don’t need separate row and column stores for transactional and operational reporting data. Plus as Hasso Plattner says, we can use the DR instance for read-only queries for operational reporting.
That is what SAP thought at this time, but then in SPS08, suddenly SAP added rows oriented tables to HANA. Yes, running an entirely column-oriented database for a transaction processing system never made any sense. Appleby himself describes this change in our critique of his article in How Accurate Was John Appleby on HANA SPS08? This article is written in November 2014, and in June of 2014, or seven months later, SAP already had to change its design.
Therefore, what Appleby states here is reversed. HANA’s performance for ERP systems must have been atrocious before they added row oriented stores.
More analysis of this quote can be found in the article John Appleby, Beaten by Chris Eaton in Debate and Required Saving by Hasso Plattner.
This is strong evidence that SAP did know what it was doing when it first designed the S/4HANA data model and has been backtracking from its original design through successive releases. Its earlier statements are contradicted by adjustments it made to the data model in later versions of HANA.
Customers that bought HANA much accepted the “simplification” of the data model without questioning if it was actually improved.
SAP could have dramatically improved the data model with true simplification. This is true of almost any software vendor, but more so for SAP ERP because most of the application was designed before modeling tools were anything like we have today.
Recreating ECC’s data model in modern modeling applications shows many opportunities for improvement.
But that was not what SAP did.
They redesigned the data model for reporting or analytics, went all-in on the column-oriented table design, and then got caught in a design problem as they had to keep adding row-based tables. This would be like a person buying a sports car and then figuring out that they need to live in it, so they put a camper on top.
SAP still claims this hodgepodge design outperforms any other database — and like a person, if they made this claim about their Frankenstein sports car/camper hybrid, they refuse to allow any competitive benchmark. Just as a person with the Franken-car I described would refuse to race anyone in their contraption.
As one commenter, I was discussing this topic with.
“If you have no technological know-how, you are at SAP’s mercy, and they haven’t been educating the community enough on their flagship database.” – Simone Sailer, Managing Editor of e3zine.com
I thought of creating a list of knowledgeable SAP customers and using the SAP HANA list to make the determination. And recall, its the most expensive database that you can buy in the category — that is the pricing right off of the price list. Our position is that HANA has the highest TCO of any database also.
The Future & What To Do About It
SAP will never admit any of this. Customers would have to pressure SAP to change. Honestly, HANA can be improved by merely using an open-source database like MariaDB or PostgresSQL — but the issue is certification and compatibility. SAP has pushed application code into the HANA, and it controls the process — and so they are stuck using HANA. HANA decreases the value of S/4HANA to customers.