- For years SAP proposed that applications on HANA would remove the need for a data warehouse.
- Now the message is changing, and B/4HANA is back in the mix.
The original presentation of S/4HANA was that because of HANA, and the reporting schemas would no longer be necessary. The elimination of the data warehouse would be possible because S/4HANA would report directly off of the column-oriented tables, which were optimized for reporting.
Part of the point of S/4HANA was to minimize the use of the need for the data warehouse. The idea went, that if all SAP applications used HANA, and a company used all SAP applications, then they would no longer need a data warehouse. SAP described this as using embedded analytics, which we covered in the article What is the Value and Future of SAP Embedded Analytics?. This vision, of course, left out entirely the reports that go across applications, which, of course, still required a central repository, which shall we call a “data warehouse.” We quote from the following to illustrate how on SAP consulting company explains this undeniable fact.
“To achieve this, you need a system that can collect, merge and harmonize data from various sources. A single S/4 system cannot achieve this. SAP does not recommend using embedded analytics to consolidate data from multiple systems, and it is meant for operational reporting only. Even though the S/4 system comes with an embedded BW system, it is not designed to be used as your enterprise data warehouse.”
And illustrated in this slide.
And this quote from SAP.
“Most of us would have for sure thought for once that Embedded BW on S4HANA would replace BW as whole and would not need BW in future. Which is kind of myth looking at the basic nature and capabilities of the EDW(Enterprise Data Warehouse). Its correct the Embedded BW can be used to support certain business processes on SAP Business Suite and S4HANA like BPC optimized. However, there are many other reasons why we can’t use Embedded BW for all the EDW needs. Based on many documents and notes following are the major reasons for which it becomes obvious to use SAP BW4HANA”
Again, who created this “myth?” Let’s not be coy about this. SAP proposed this myth.
Over several years, I don’t recall telling people that HANA would lead to the elimination of the data warehouse. Quite the opposite, and those people telling me that I need to get with the “brave new world of analytics” within each application were SAP consultants. Even in private, with no one listening, the adherence to SAP talking points by SAP consultants never ceases to amaze me.
Who Thought This Illogical Approach Would Work and Evangelized The Design?
Usually, the less technical the resource, the more they thought this would happen, with salespeople who had never personally worked with databases or analytics software being the most blatant that this was the future that HANA allowed. They topped this off by proposing that only SAP had the vision to make this happen. This following quotation is verbatim.
“Hasso Plattner always hated analytics systems. He saw them as a failure of the application to provide the reporting. His vision is to eliminate the data warehouse, and HANA is how he will do it.”
SAP Analytics Products are All Jumbled In
Another undiscussed issue is how many products are now part of this solution. Let us review a slide.
This slide is already a bit out of date as Lumira has been discontinued, and Cloud for Analytics is the replacement product. But let us review all of the products that are part of this design.
- SAP Cloud for Analytics
- SAP Business Objects
- SAP Lumira
How much are all of those licenses going to add up to? Is this us, or does this appear like a confusing combination of items?
The New Reality of S/4HANA and the Data Warehouse
Years after, SAP presented this vision, and they are now changing their story regarding data warehousing. SAP is now proposing that customers use something called embedded BW. This is the junior version or BW/4HANA, which is the more advanced version that is merely the rebranded stand alone BW, but which, of course, only runs on HANA and pushes out other database vendors from the mix. Embedded BW is implemented within S/4HANA and, according to SAP, is for “strategic analysis” rather than the standardly embedded analytics that are for more or less canned analytics.
We have been saying for some time that the embedded analytics in S/4HANA are simply for canned analytics. Because they are canned, they don’t even leverage HANA as they can be pre-compiled, with only net change information updated.
One of the reasons it’s very easy to overestimate the number of apps or tiles of functionality included in S/4HANA is because so many of the tiles are just reports, as the slide above illustrates. Once in the transaction/report, there usually is not much that one can do other than some necessary searching or filtering.
It is understood that more analytics than the canned “embedded analytics” are required for non-standard reporting, but why did SAP port an obsolete product like BW to S/4HANA? One of the main points of HANA was that a heavy overhead BI environment with their hefty maintenance overheads like the SAP BW was supposed to be no longer necessary.
Column-Oriented Tables: A Simplified Data Model
Recall the simplified data model? We covered the topic in the article, and contradicted the notion that S/4HANA had a simplified data model in the article Does S/4HANA Have a Simplified Data Model?
However, while the data model is no simpler, it is, that is, column-oriented tables, are certainly more optimized for read access or that is for reporting and analytics. The idea that was presented by SAP was that a simpler, lighter BI environment, for instance, like Lumira (now discontinued), or SAP Analytics Cloud (not yet ready to be implemented) or a mature visualization product like Tableau or Qlik was supposed to be able to be used. So far, the number of application of HANA has been for the BW, which speeds BW, but does little to reduce the lengthy reporting queues sitting behind most BW implementations globally.
Continuing to Work Off of Data Cubes?
Something else odd was that there are graphics that show both embedded BW and B/4HANA using data cubes. They also work off of Core Data Services that feed the data cubes, which we covered in the article How to Understand HANA Lock in with Core Data Services.
Again why are either of these products using data cubes? Data cubes are actually not cubes; they are star schemas that are designed to speed row oriented tables. The point of using columnar tables is so that they can read accessed very quickly without any intermediate object such as a star schema.
SAP Backtracks on the Design Proposals of HANA
The story around SAP analytics keeps getting weirder and more complicated, and it contradicts what was supposed to be the primary benefits of HANA.
With new articles coming from compliant SAP consulting companies, we have the explanation that companies still need a data warehouse, which means that SAP’s vision of entirely embedded analytics has failed. Alternatively, should we say, what SAP stated about doing away with the data warehouse because of the embedded analytics will never come true? We knew it would never come true, as it never made any sense. We told many SAP consultants this in discussions, but they overrode the concerns and told us this all made sense at SAP. Five or six years after the fact, SAP is finally changing it’s messaging (although not admitting it is changing its messaging).
SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos
Fact-Checking SAP’s HANA Information
This video is filled with great 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: A Lack of Fact-Checking of HANA
There are two fundamental problems around HANA. The first is the exaggeration of HANA, which means that companies that purchased HANA end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts, there is no independent entity that can contradict statements by SAP.
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
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 BI on HANA 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