When Articles Exaggerate SAP HANA Benefits - Brightwork Research & Analysis

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

Executive Summary

SAP HANA has an enormous number of exaggerated articles.
We cover the accuracy of the proposals contained in these articles.

Video Introduction: SAP HANA Exaggerations

Text Introduction (Skip if You Watched the Video)

What became apparent in reviewing articles on SAP HANA is that they tend to have a high “aspirational content” ratio. Any potential software buyer needs to be concerned with SAP HANA articles’ tendency to take on a playful and exaggerated nature. Our research to understand what supports these statements found that it often turns out to be nothing at all. A large number of these articles seem to propose benefits that are supposed to be uncritically accepted by the reader. In this article, you will learn about the exaggeration undertaken by SAP on SAP HANA.

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.

Aspiration for SAP HANA Benefits!

For example, one of the common issues that I find is that while the benefits are listed, the costs are not. How costs are addressed is by asserting that SAP HANA reduces TCO. How much seems to depend on the entity proposing. According to SAP, the TCO reduction is “dramatic.” According to Capgemini, the TCO reduction is “huge.”

What are these things based upon?

The only study I could find on this was an SAP commissioned study from Forrester Research back in 2014. In How Accurate Was Forrester’s TCO Study for SAP HANA? I critiqued the Forrester study. Long story short, it is so filled with holes that I believe the study lacks any validity whatsoever. SAP got what they wanted out of Forrester, but no one should consider this seriously.

Interestingly, what is left out of all references to the study is that the cost savings are entirely projected.

A lot of other articles seem to be confused as to distinctions cost and benefits analysis as they commingled ROI with TCO. Sufficient to say, if you cannot keep ROI separate from TCO, then it isn’t easy to take that author and that article seriously.

How Many Extra Costs to Properly Maintain HANA?

SAP HANA dramatically changes a company’s approach and skills it needs for SAP and has all types of associated extra costs. SAP emphasizes the dramatic changes, but it positions them entirely as cost and effort reduction.

That is incorrect and misleading.

It makes no sense to continually transition so quickly from the costs to the benefits side of the equation. Moreover, now that we are on the subject, the benefits that are attributed to SAP HANA, at least by many authors, are another big problem with the information published on SAP HANA.

Focusing on the Declared SAP HANA Benefits

To illuminate this point, I will provide a list of SAP HANA benefits. This is a direct quotation from an article produced by a senior member of one of the major SAP consulting companies.

After reviewing this list, let us perform a little test to see how many of the items relate to SAP HANA benefits.

“Some focus on the details of the technology. But why should business leaders care? Those who have recognized that in-memory computing allows them to do things differently have realized these benefits:

Ease of integrating data from multiple sources
Increased speed to deployment and speed to value
Flexibility to meet changing business needs
Enhanced mobile analytics
The power to turn data into action.”

Now let us go through each item to see if these are true:

Total Integration with S/4HANA?

SuccessFactors, Fieldglass, Concur, Ariba are not all integrated into S/4HANA. SAP states that they all sit on the same database! That is untrue. However, again, with how SAP treats time when it makes statements, SAP may be saying this will be true 5-10 years from now. If the projections can be unlimited across the timeline, then anything can be said to be true.

Secondly, outside of S/4HANA Finance, S/4HANA does not exist as it is not released. (I have a future article on this as some consulting companies are proposing to clients that version 1511 is a completed product) An ancient Chinese proverb says that “You cannot be integrated into an application which does not exist — grasshopper.”

*One commenter stated that by using a slide from S/4HANA, I appeared to confuse S/4HANA with HANA. This slide, while about S/4HANA, is also about HANA itself as it proposes that all these applications are integrated on SAP HANA. That is incorrect. It is the exact opposite of what this slide presents in real life.

Integration as One of the SAP HANA Benefits?

“Ease of integrating data from multiple sources.” – SAP

I do not recall in-memory computing being referenced before as improving integration. Readers can check the Wikipedia entry on In-Memory Computing and In-Memory Database, and the word “integration” does not appear a single time. Isn’t that a bit concerning?

This brings up a logical and factual problem that undermines the credibility of so many SAP HANA benefits articles. The items tend to morph the benefits from one area to another field. Specifically, this is a major weakness in the articles by Hasso Plattner, who shows a pattern of writing disjointed articles that commingle multiple topics — often in a single sentence. The strategy seems to be to combine so many proposals that they overwhelm the reader into agreeing. Alternatively, as my friend likes to say, “it is all about the Big Data now.”

Let the competition between simplistic platitudes begin.

Back to the specific statements. SAP HANA does not provide any extra ease of integrating data from multiple sources as it is not an ETL (extraction, transformation, and load) tool. SAP’s ETL tool is called SAP PI/PO. The background idea here may be that everything will run on one giant SAP HANA instance so that data can be moved between the applications. However, we are far away from that state.

Moreover, also, why would every application want to sit on the same SAP HANA database? SAP HANA is only optimized for reporting processing. This gets into the question of HANA performance, which does not, as SAP has stated, work equally well for either analytics or transaction processing.

Before we make projections reducing ETL, let us acknowledge what is currently proven and what is conjecture. SAP HANA proponents continuously transmute time.

Conveniently Switching Between Doing Now and Doing in the Future

If you want to climb Mount Everest, then that is in the future. You cannot logically describe your experiences of climbing a mountain you have never climbed.

HANA is the database, and the more quickly we can move away from referring to it as a platform, the more we can make progress in understanding what HANA does versus what it does not do.
We have to decide where we are going to “live mentally” when understanding SAP HANA. If we want to live in the land of marketing hyperbole, then we can call SAP HANA a platform and transmute time and ascribe benefits to SAP HANA, which have never been proven. However, unless one works in SAP marketing, it makes little sense to accept any of their proposals without independent verification that they are true.

Is “Faster to Deploy” One of the SAP HANA Benefits?

In most cases, HANA will not provide an…

“increased speed to deployment and to value.” – SAP

First, you cannot be faster to deploy than something that is already installed. HANA is replacing databases that are already deployed. I would very much like to see HANA implemented quicker than an already deployed database.

Do you see a pattern here?

We seem to get back into the topic of time transmutation repeatedly. Luckily the Dr. Strange movie is coming out soon, so I will be able to get on the same page with all the time alterations that are so familiar with HANA proponents.

However, that is just a beginning point, even if we start from two new systems being compared, HANA will take longer to implement because it is more sophisticated and less tested than previous SAP products. Aside from the speed of implementation question, it also means higher risk. Anyone who thinks that new products implement faster than older products with many implementations does not work in software and does not know SAP.

Now, there may be a higher payoff, although that is not proven in any of the articles on HANA. However, the risk and project duration should account for the relative newness of HANA.

A Good Idea to Migrate BW to HANA?

The one case where this may not be the case is with a BI/BW implementation. When BW is implemented on top of HANA, it means time saved through less time spent configuring the Data Workbench. However, that is only for a fresh installation. For companies that already configured the data structures, it will mean there is now less of a need for those structures. Moreover, of course, HANA is a pure analytics database design, so it will always work best for analytics applications like BW. However, no other SAP application should be expected to receive this implementation benefit.

So this quotation should be changed to

“May be faster to deploy under some limited circumstances.”

Flexibility to Meet Changing Business Needs one of the SAP HANA Benefits?

“Provide flexibility to meet changing business needs.” – SAP

HANA will not provide flexibility to meet changing business needs unless that changing business need is processing something faster….and something processed faster for analytics. Moreover, SAP has provided no evidence that HANA performs analytics processing faster than alternatives — as is covered in the article What is the Actual Performance of HANA.

It sure seems like I have to keep pointing out this fact to authors on HANA. HANA is a database; it is not application functionality.

Application functionality is where addressing changing business needs are typically met.
The database layer is where data from the application is stored.

This issue has arisen from SAP itself when it tells clients that things like HANA will replace APO, which again is like saying Oracle 12C will replace APO or replace CRM. It is both incorrect and confusing to say that a database returns an application.

So let us establish an essential feature of the software.

Databases do not replace applications. What SAP meant was that IBP, which is APO’s potential replacement, would replace APO, and IBP runs on HANA. However, that is a much different statement.

HANA for Mobility one of the SAP HANA Benefits?

“Enhanced mobile analytics” – SAP

You seriously don’t need HANA for mobile analytics; check what the emphasis point is in mobility from any of the other analytics vendors. They do not emphasize the backend.

It is hard to see why this would be claimed as a benefit for mobile computing. This is because the bottleneck on mobile computing has far more to do with the bandwidth than the database. Also, SAP has, in effect, no mobility business, and won’t for the foreseeable future. SAP fought that battle and could not compete with low-cost and high-quality iOS development. So is SAP proposing that its database will speed mobility applications that are not SAP?

The uptake on Fiori will have something to with this as Fiori, although not admitted to by SAP, is primarily a mobile application. However, Fiori’s future is unknown at this point. (not good, not bad, just unknown) However, there is no evidence to support the contentions by SAP and their partners that Fiori is the future.

Right now, almost no one uses Fiori. See my articles on Fiori for why this is the case.

Convert Data Into Action as one of the SAP HANA Benefits?

“HANA allows companies to convert data into action.” – SAP

This is true, but it seems like someone’s catchphrase or something to be put on a bumper sticker. So it is not false; it is irrelevant as a differentiator.

Any application converts data into action (or technically the potential for action).

If one thinks about it, data has been translated into action by devices since before computers were invented, as the counting boards (the earliest known counting device) used by the Babylonians also could convert data into action.

One Example of A Correct Statement?

The one example from the list of something that sort of can be considered to apply to HANA can also apply to counting boards…and that cannot be a good thing.

Go to top

Conclusion

These types of articles/promotional material on HANA are all too familiar. The information in them is entirely unreliable. They are designed to get prospects bubbly and to reach out to them. This misinforms the reader and gives the reader nothing in return for their attention. They are published by Accenture/IBM/Capgemini/Infosys…(fill in the blank), all of whom have shown a willingness to make any statement that they think will increase their revenues. None of them have any independence from SAP.

Believing them increases the risk of software implementation.

What is possibly most interesting is that many of the supposed improvements that are listed in these types of articles are not improvements that can be traced back to HANA.