- SAP proposes that ERP and Big Data should reside on the same database.
- We evaluate the reasonableness of this proposal.
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 proposed and whether if it is feasible.
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 proposed, because of the universal Swiss Army Knife aspect of HANA, that SAP customers can stop moving data out of the ERP system (and in fact all systems, but lets keep to the more simple version of the argument) and 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 places data from applications where they originate into data cubes. These data cubes can be actual cubes called MOLAP, or emulated cubes called ROLAP. For the purposes of 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 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 the 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 actually 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 Problem with SAP’s Single Database Proposal
- 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 exactly 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 am hearing 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 fairly obvious that SAP should not have done this, but increasingly it is appearing 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, who were simply repeating SAP marketing literature in order 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.
- 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.
- 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 horribly inefficient backend where the data cubes are created. Yet, while the expensive hardware, software and consulting are a certainty with respect to implementing HANA, the savings are simply predicted. And in case anyone is curious, SAP’s ability to predict cost savings is not very high.
- 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 an expensive 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.
- 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 very small. I have reviewed all of SAP’s claims in this area, as have many others, who are not at liberty to write publicly on the topic, and the arguments have been found to be deceptive. SAP has created a very expensive database and there is no way around that fact. SAP created the compression argument to combat the very real perception that HANA is so expensive.
- 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.
SAP is presenting a 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 really not all that compelling. Secondly, even if the vision were compelling, there are very large barriers, including SAP’s own 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.
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 S/4HANA Content
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model