Why Pressure SAP to Port S/4HANA to AnyDB? - Brightwork Research & Analysis

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Oracle presents an excellent case for not following SAP on implementing S/4HANA.
We explain the logic for pressuring SAP on creating S/4AnyDB.

Video Introduction: Why Pressure SAP to Port S/4HANA to AnyDB?

Text Introduction (Skip if You Watched the Video)

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. All of this comes with HANA, but with very little in the way of other benefits — and enormous long-term maintenance costs as well as database lock in. SAP and SAP consulting firms have been covering up this liability and even coming up with “objection handling” reasons why it is not a problem. You will learn what SAP and their consulting firms are hiding from SAP customers.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
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. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

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 for 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. HANA’s database design 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 S/4HANA or any ERP systems used, as we cover in the article How to Understand the Issues with BW EML Benchmarks.

The upshot is that SAP is imposing a costly and high overhead database with a significant remediation overhead (in addition to the overall high cost of HANA).

SAP and the SAP consulting companies have been minimizing the code remediation effort for S/4HANA to lull customers into a false sense of the work effort involved in increasing their ability to sell customers on S/4HANA. There was not a single mention of the code remediation to the customer by either SAP or Deloitte at one recent account.

We disagree with the major SAP consulting firms; our recommendation is to pull forward the code remediation analysis before the project begins. And to ignore all advice that comes 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).

The 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 an inferior value for any ERP system. 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 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 BW application benefit is reduced because the BW Data Workbench was where the star schemas were created. Once HANA was introduced and, by extension, other databases with columnar capabilities, the work is 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.

Oracle continues…

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 application vendors’ data models.

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 most 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 don’t, then it is a good idea to skip this person’s medical advice.

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?

SAP has presented its neophyte data model, which overly relies on columnar tables, and has had to have row-oriented tables added to its initial design.

It is important to remember that when SAP first introduced HANA, 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.

Go to top

Conclusion

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

Bingo.

I thought of creating a list of knowledgeable SAP customers and using the SAP HANA list to determine. Recall it’s the most expensive database that you can buy in the category — that is, the pricing right off 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.