SAP HANA Architecture

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

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.

Introduction

SAP has been proposing for some time that there would be a massive change in how data is stored and analyzed. In this article, we will cover what SAP has recommended and whether if it is feasible.

See our references for this article and related articles at this link.

SAP’s Proposal

Since HANA was first introduced, 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 with the way that 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 for many years, data cubes were the standard approach for improving the read speed, and therefore the report run speed of data.

With the combination of the column-oriented table design, which 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, as 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 been in creating 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

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, which is 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 the development of HANA.

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 were simply repeating 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 very expensive hardware, software, and consulting. Their payback is that they 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 a 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 simply 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 very expensive 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 the 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 do.

Conclusion

SAP is presenting fantasy to customers. The intent to provide such an overwhelming vision, that their customers simply purchase HANA. So that their customers want to move to S/4HANA so that they can receive all the benefits of running ERP and reporting off of 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 lead companies like Kaeser Kompressor to propose even more unrealistic visions, such as a single database for not only the ERP system and for reporting, but for Big Data as well.