SAP's Big Idea: ERP Data and Big Data on the Same Database?

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

Executive Summary

SAP proposes that ERP and Big Data should reside on the same database.
We evaluate the reasonableness of this proposal for using one giant database.

Video Introduction: SAP’s Big Idea: ERP Data and Big Data on the Same Database?

Text Introduction (Skip if You Watched the Video)

SAP has been proposing that there would be a massive change in how data is stored and analyzed. SAP is proposing this for one reason:: it wants to pretend it has thought leadership and coax its customers into moving to HANA. SAP’s proposal of how HANA can support their vision falls apart once their claim is analyzed and one reviews their claims with our research into HANA. You will learn what SAP has recommended and whether it is feasible.

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.

SAP’s Proposal

Since SAP first introduced HANA, SAP has been proposing that HANA can do all types of database processing, transaction, analytics, read, write, insert, etc. SAP has suggested, because of the universal Swiss Army Knife aspect of HANA, that SAP customers can stop moving data out of the ERP system (and all systems, but let’s keep to the more simple version of the argument). It can run all reporting on the ERP system.

This would break how reporting/analytics has been previously set up, where the data is migrated to a specialized data store, called a data warehouse. In the current solution design, for instance, when ECC is used with either BW or BusinessObjects, either BW or Business Objects sits on the data warehouse.

Important Foundational Logic to the SAP Proposal

The foundational logic to this proposal is found in the column-oriented database design. The column-oriented table is optimized for reading access. Both BW and BusinessObjects place data from applications where they originate into data cubes. These data cubes can be actual cubes called MOLAP or emulated cubes called ROLAP. For this article, the distinction is not important. What is important is that data cubes were the standard approach for improving the read speed for many years, and therefore the report run speed of data.

The combination of the column-oriented table design contains special advantages when combined with the data to be accessed being placed into memory (as is explained in the article How SAP HANA is Such as Fast Database), data cubes are no longer necessary. SAP has not done much with this ability; however, SAP’s customers already invested in creating data cubes and “universes” (a BusinessObjects term) in their data warehouses. So while it is a relatively straightforward manner to take BW and place it onto HANA, it is far less simple to reverse engineer all of the data cubes that have been built up over the years. So the data cubes that have been created in the past mostly stay in place. Much of the software development in BW and BusinessObjects has created a backend that allows data to be accessed more quickly. This is a capability that has been addressed with a combination of hardware and database table design.

The concept behind doing away with the data warehouse and simply combining the ERP system with the reporting system on a HANA database is what I have covered up to this point. However, the following SAP promotional video takes the concept a step further but stating that not only would reporting be placed on HANA, but HANA would also be a location for Big Data.

The Kaeser Kompressor Case Study Explanation

This video was deleted from YouTube by SAP.

Has Kaeser Kompressor moved to reporting, Big Data, and running ERP off of a single database? Or, is Kaeser Kompressor describing a concept that SAP has put forward that sounds appealing?

The Problems with SAP’s Single Database Proposal

Issue#1: HANA’s Claim to be a Swiss Army Knife

SAP has asserted that HANA is equally good at all types of data processing. However, it has provided no evidence to back up this claim. SAP has stopped performing a benchmark for transaction processing, precisely the type of processing that HANA could be expected to be poor at performing. This is covered in the article What is the Real Performance of HANA? Secondly, what is very well known by SAP (as I have spoken to people inside of SAP) is that SAP is poor at writing data to the database. This may not be all that surprising as column-oriented tables are inferior to row-oriented tables for writing data. However, the number of problems that I hear about on projects that use HANA for S/4HANA indicates that SAP may have made some tables that should have been kept as row-oriented to be column-oriented. It should have been reasonably evident that SAP should not have done this, but increasingly it appears as if SAP did make mistakes in HANA’s development.

These design problems fall in stark contrast to the marketing material released by SAP and effusive articles written by people like John Appleby of Bluefin Solutions. They simply repeated SAP marketing literature to ingratiate themselves to SAP by publishing information that built up HANA expectations to a fever pitch, as is covered in the article How John Appleby Was So Wrong in his HANA Predictions.

Issue#2: Reversing the Work Done in Data Warehousing

SAP is proposing a radical change in how the analytics/reporting systems are set up. It means reversing course and removing large amounts of investment that companies have already implemented.

Issue#3: Buying New Hardware and Software

A customer must purchase costly hardware, software, and consulting. Their payback might incur lower future costs in both integration (no integrations to the data warehouse from ERP or any other application would be necessary) and IT labor as report developers would no longer need to create complex data structures like data cubes to reach the desirable report speed. SAP BW, in particular, is saddled with an inefficient backend where the data cubes are created. Yet, while the expensive hardware, software, and consulting are a certainty concerning implementing HANA, the savings are predicted. And in case anyone is curious, SAP’s ability to predict cost savings is not very high.

Issue #4: Purchasing S/4HANA

One can run ECC on HANA, called Suite on HANA, but SAP wants customers to move to S/4HANA to receive the proposed vision. ECC on HANA is an expensive proposition. S/4HANA is not only a costly proposition; it has a far higher probability of failure than success. S/4HANA is an immature application that has very little implementation success. This is covered in the research The S/4HANA Implementation Study.

Issue#5: HANA’s Cost

HANA is the most expensive database on the market. It is priced per GB, and its price is very high per GB. HANA is one of the only databases to be sold this way. And this means that it is not feasible to keep very much data in HANA. SAP has a comeback on this, which is that HANA compresses so that the data footprint is, in fact, minimal. I have reviewed all of SAP’s claims in this area, as have many others, which are not at liberty to write publicly on the topic, and the arguments are deceptive. SAP has created a costly database, and there is no way around that fact. SAP created the compression argument to combat the real perception that HANA is so expensive.

Issue# 6: Big Data

The Kaeser Kompressor video pushes the concept into ludicrous territory. No company would place large amounts of unstructured data into HANA. Firstly, HANA is not a Big Data database. It is a column-oriented design, not an unstructured repository like NoSQL or Hadoop. Secondly, even if for some strange reason it wanted to, it could not afford to do.

Go to top

Conclusion

SAP is presenting fantasy to customers. The intent to provide such an overwhelming vision that their customers purchase HANA. Their customers want to move to S/4HANA to receive all the benefits of running ERP and reporting off a single database. However, upon analysis, this vision is not all that compelling. Secondly, even if the vision were compelling, there are huge barriers, including SAP’s pricing of HANA, the maturity of S/4HANA, to making the vision a reality. Furthermore, SAP’s proposal on this topic has led companies like Kaeser Kompressor to propose even more unrealistic visions, such as a single database for the ERP system and reporting, but Big Data.