- 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 large liability in its data model which requires extensive code remediation.
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, and 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 refuses 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 large remediation overhead (in addition to the overall high overhead 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 entirely 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 on the basis of 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 certain 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 in 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 greatly 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 PhD?
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 their 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 absolutely 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 releases of HANA.
Customers that bought HANA basically 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 a 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 conundrum as they had to keep adding row-based tables. This would be like a person buying a sports car, an then figuring out that they actually 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 actually 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 simply 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.
SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos
Fact-Checking SAP’s HANA Information
This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.
SAP Video Accuracy Measurement
|SAP's Statement||Link to Analysis Article|
|HANA is a Platform||HANA is not a platform, it is a database.||How to Deflect You Were Wrong About HANA|
|HANA runs more "in-memory" than other databases.||HANA uses a lot of memory, but the entire database is not loaded into memory.||How to Understand the In-Memory Myth|
|S/4HANA Simplifies the Data Model||HANA does not simplify the data model from ECC. There are significant questions as to the benefit of the S/4HANA data model over ECC.||Does HANA Have a Simplified Data Model?|
|Databases that are not HANA are legacy.||There is zero basis for SAP to call all databases that are not HANA legacy.||SAP Calling All Non-HANA DBs Legacy.|
|Aggregates should be removed and replaced with real time recalculation.||Aggregates are very valuable, and all RDBMS have them (including HANA) and they should not be removed or minimized in importance.||Is Hasso Plattner Correct on Database Aggregates?|
|Reducing the number of tables reduces database complexity.||Reducing the number of tables does not necessarily decrease the complexity of a database. The fewer tables in HANA are more complicated than the larger number of tables pre-HANA.||Why Pressure SAP to Port S/4HANA to AnyDB?|
|HANA is 100% columnar tables.||HANA does not run entirely with columnar tables. HANA has many row-oriented tables, as much as 1/3 of the database.||Why Pressure SAP to Port S/4HANA to AnyDB?|
|S/4HANA eliminates reconciliation.||S/4HANA does not eliminate reconciliation or reduce the time to perform reconciliation to any significant degree.||Does HANA Have a Simplified Data Model and Faster Reconciliation?|
|HANA outperforms all other databases.||Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.||How to Understand the Mismatch Between HANA and S/4HANA and ECC.|
The Problem: The Negative Consequences of Using S/4HANA
This is why independent advice is necessary on SAP S/4HANA and HANA because SAP is providing false information and their consulting partners simply parrot this false information. Oracle has the incentive to provide inaccurate information that moves customers away from BW on HANA, but while the incentive is there, here Oracle is correct. Secondly, SAP S/4HANA design is wasteful. It requires extensive code remediation to adjust for a radically different data model but does not lead to performance improvements in S/4HANA. Oracle, and other database vendors that have made similar adjustments to their database offer the opportunity to use S/4HANA without a major reconfiguration of the data model. The problem, of course, is that SAP does not allow this option.
Being Part of the Solution: What to Do About S/4HANA
SAP still does not have S/4HANA ready to be implemented. Most companies that have tried to implement S/4HANA have failed to bring S/4HANA live. In the case of Revlon, it caused a major disruption to their business as we covered in the article What Was the Real Story with the Revlon S/4HANA Failure? SAP has little leverage to force companies to migrate to S/4HANA, but both SAP and SAP consulting companies are desperate for license revenue and implementation money from S/4HANA. This means that SAP customers could coordinate to push SAP to port S/4HANA to other databases. There is no reason, aside from migrating some of the code out of HANA to the application layer, why this could not occur. If SAP customers were savvy, they could coordinate and demand that S/4HANA be ported to S/4AnyDB, and this would mean using the previous data model (that is with adjustments for the removal of S/4HANA functionality that occurred from ECC to S/4HANA). That would meet the requirements for companies to move to S/4.
We ask a fundamental question that everyone that works in enterprise software should ask themselves.
Should decisions be made based on sales information provided by 100% financially biased parties (consulting firms, IT analysts), to companies that do not have internal fact-checking capabilities?
If the answer is “No,” (contact us if you think the answer “Yes“) then perhaps the present system of decision making should be improved.
If you are worried about getting the real story, we can help. We have a history of proving accurate fact-checking analysis. We also have no financial connections to any entity we fact check.
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.
S/4HANA Implementation Research
We offer the most accurate and detailed research into S/4HANA and its implementation history. It is information not available anywhere else and is critical correctly interpreting S/4HANA, as well as moderating against massive amounts of inaccurate information pushed by SAP and their financially biased consulting ecosystem.
Select the description that best matches you.
Option #1: Do You Work in Sales for a Vendor?
See this link for an explanation to sales teams.
Option #2: Do You Work for an Investment Entity that Covers SAP?
See this link for an explanation for investment entities.
Option #3: Are You a Buyer Evaluating S/4HANA?
For companies evaluating S/4HANA for purchase. See this link for an explanation to software buyers.
Search Our Other SAP S4HANA DB Portability Content