- 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 than 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 obvious 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?” Lets not be coy about this. SAP proposed this myth.
Over a span of 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?
Normally 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 vociferous 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 which is the junior version or BW/4HANA which is the more advanced version that is merely the rebranded stand along 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 its very easy to overestimate the number of apps, or tiles of functionality included in S/4HANA is because so many of the tiles are really just reports, as the slide above illustrates. Once in the transaction/report, there is normally not much that one can do other than some basic 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 very heavy 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 which 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 were supposed to be the original 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 its messaging (although not admitting it is changing its messaging).
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
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