How to Deflect That You Were Wrong About HANA - Brightwork Research & Analysis

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

Executive Summary

SAP and SAP consulting firms have made a large number of false claims around HANA.
When confronted with these claims, HANA proponents continually change the topic and deflect other HANA claims that are also false.

Video Introduction: Deflection of HANA Claims

Text Introduction (Skip if You Watched the Video)

There is a popular trend afoot in the HANA community from either HANA defenders in SAP or HANA defenders in the SAP partner community. We call this pretending you weren’t wrong about HANA. SAP and its partner community have generated so much false information about HANA over the past five years. Once called out on it, they need to respond not to be seen as either unknowledgeable or dishonest. There are important principles at work here. Let us take a minute to review them. There is HANA software to be sold! There are HANA services to be sold! It is imperative to be able to continue to mislead customers in an unmolested fashion! You will learn the essential tactics that HANA salespeople and HANA consulting companies employ.

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.

First Some Background on the HANA DB

HANA DB was at some point around 2011 approved as the primary marketing tentpole for SAP. Since 2011 Dr. Hasso Plattner has written four books on HANA DB related topics. SAP marketing and sales have released a torrent of information about HANA. My research shows that this information has in just about every case been either inaccurate or exaggerated. Dr. Hasso Plattner seems to be a true believer in HANA. Somewhere along the way, he seems to have become obsessed with HANA DB technology. People at SAP did not stand up to him and tell him he is overemphasizing one topic (to the detriment of other important issues). I have brought upon many occasions that processing speed is not among the top ten items that plague SAP projects. And if you work on SAP projects, it is hard to propose the opposite.

Fear of Confronting Hasso

Instead of having anyone push back on Hasso, SAP went all-in on HANA. The problem is that Hasso is not a reliable source of information on computer topics. I have concluded that Hasso Plattner makes up things about as much as Donald Trump. The major difference is that Hasso Plattner is considerably smarter. And he covers topics that are far more sophisticated than the subjects covered by Donald Trump. Thus his deceptions are much harder to ascertain. But if you study Hasso Plattner’s writing and speeches long enough, a pattern of intentional deception becomes impossible to ignore. The comments he made about a Chinese company that had an MRP run time of 24 hours, which SAP reduced with S4 running on HANA, many months before S4’s production planning module had even been developed, is symptomatic provably false statements made by him. (I have a future example of a very long MRP runtime, but alas, the conclusion is not purchasing HANA DB.)

Hasso is much like most of the partners at large consulting companies that I have met. They simply do not care what happens. What they care about is what they can pull over on other people. This is not idle criticism but is based upon quite a few conversations with partners at major consulting companies about what they care about the perception rather than reality. And they have told me that this is the right way to think.

Follow that Money that Supports False Claims Around the HANA DB

As is usually the case, the vast majority of money resides in those who make exaggerated claims. The money is squarely on the side of exaggerating expectations, not on telling people the truth. The truth is much less exciting and does not appeal to the desires of the audience. The audience wants to hear that the thing they purchase will have incredible performance. That everyone who uses it loves it, that it is leading-edge, has a low TCO, which will result in being able to cut overhead, etc..

Things have not changed much since the traveling medicine show salesman. Wall Street wants to hear that SAP is all about driving innovations through HANA and delivering more and more applications through the cloud. Therefore, regardless of what is true, the data will be gerrymandered to give this impression. Quotas must be met, and stock options must be exercised. SAP can choose from an unlimited number of type people who will tell any lie SAP wants in any language it wants in return for money.

For this reason, people in conferences and private visits compete with each other to misrepresent reality.

And the competition is fierce.

SAP Conferences as BS Mills

Conferences like SAPPHIRE and ASUG are filled with false information. Lies were emanating not only from SAP and their partners but employees within customers. They compete in giving misimpressions on how much progress they have made with SAP’s newest applications. In interviewing companies that interact with SAP and SAP partners and I observe the information provided to these enterprises. I find one misleading statement after another. I should not be surprised. The lying in the documentation is simply repeated in the actual sales process.

There is all manner of problems with this overemphasis on HANA DB. But one easy item to point out is that the system’s overall performance does not match the system’s database speed. That is because you can make the database run faster by, say, 100 points of measurement do not mean that this 100 point translates to 100 points in application performance. And whatever the improvement in application performance does not translate to business value.

False Performance Enhancements Applied Generally

Think about a Lamborghini Veneno. This $400,000 car has a 750 horsepower engine.

A Honda sedan may have a 100 horsepower engine. Does the Veneno get you around town 7.5 times faster? Of course not. You can’t convince people to sell their house to buy a Veneno because everyone drives, so they can’t be tricked into thinking their commute will drop to 2 minutes if they buy a Veneno. But not everyone has years of database experience. Thus it is easier to trick them into thinking that HANA might have such incredible benefits. But if they didn’t, and I was unethical, I could simply do the math that 750 hp is 7.5 times more than 100. I would then contend that people that have a 15-minute commute could have a 2-minute commute. That is 13 minutes saved each way, which is 26 minutes a day in extra time saved!

Imagine what you could do with that time back.

Hasso Plattner’s Falsehoods on In Memory and the HANA DB

In Dr. Hasso Plattner’s writings, he seems to propose a direct proportional benefit from database speed to a host of other benefits. This has led SAP to exaggerate HANA’s benefits, and the primary reason for this is to penetrate the database layer. SAP is willing to mislead as many people as necessary to meet the sales quotas on HANA. People that buy HANA often don’t see the second act coming.

Here is the second act. SAP has some other databases and applications that it wants to sell as a follow-on to HANA. And, of course, none of these things will work well with “other databases.” HANA is the wedge to all sorts of related items it wants to sell you.

All of this fanciful talk about a brave new world with in-memory computing is part of a campaign to tie companies into a closed system. A system that will benefit SAP. I have seen many companies now with HANA on BW.

Putting HANA on BW

BW is probably the SAP application with the most predicted benefit from HANA. It has not changed things at these companies much at all. In most cases, the business continues to use Excel, while the queue of reports that the BW/BI team has to work on continues to grow. This is because new technology was added without asking the fundamental questions about BW/BI productivity and report usability problems.

This means that software salespeople and those with a sales quota at most IT consulting companies feel perfectly fine in telling a constant stream of lies to customers. Every inaccurate statement is an arrow in their quiver. Even statements that have been proven quite some time ago to be incorrect.

SAP’s HANA DB Claims

The following are good examples of the items that are exaggerated claims by either SAP or SAP partners.

No aggregates EVER!!!
Extreme OLTP performance as well as extreme OLAP performance
Need little RAM as we compress EVERYTHING to very small…
A whole new user interfaces in Fiori.
HANA will lead to business process simplification when used with S4 because the data model has been simplified.
Updates are superfast as we update only one field instead of the whole record.
Making use of CPU/RAM at the hardware level.

Every one of these proposals by SAP or by those with some HANA quota to fill is false.

False Claims About HANA

HANA DB still uses aggregates. There are, in fact, many good reasons for maintaining aggregates. Reference tables are aggregates.
SAP is not releasing benchmarks on HANA DB for OLTP because, as per HANA’s design, these benchmarks are likely to be disappointing. But this does not stop SAP from claiming that HANA DB is equally effective at OLTP and OLAP (transactions and reports — excuse me, “analytics”)
SAP’s compression estimations are greatly exaggerated and require heavy archival (a cost) and will result in companies having to go back to SAP after purchasing more HANA license GBs.
Fiori is not a complete UI for S4. Instead, Fiori is a niche set of apps. A set of apps has yet to be demonstrated to work any better than the parts of SAPGUI they are replacing. And a set of apps that, in 98% percent of cases, will only work with applications that sit on top of HANA DB.
S4’s data models are not simplified. There are more tables than ever with a column-oriented database, as many of the columns have become their tables. Indexes are eliminated with column-oriented databases. That is a reduction in complexity. But other areas increase in complexity, including the need to rewrite every single adapter connected to ECC. Simplification of data models (even if true) does not lead to simplified business processes (the SAP claim).
SAP never mentions the need to update 20 fields in one record; we end up with 20 updates instead of one update on row-based databases.
The CPU and the RAM are at the hardware level. You cannot benefit from using something at a level if it is already used at that level. This would be like saying, “you will be able to use the steering wheel at the automobile level.” There is no other way to interpret this, except it is a purposely redundant statement that is supposed to sound technical and esoteric. It is designed to impress people who don’t know how the software works.

Selling Nonsense

If you sell nonsense for a living, you will not stop just because I call you out on it. You need to obscure the issue so you can keep selling nonsense. From financial advising to medicine to IT consulting and strategy consulting, nonsense is a great thing to sell. It is excellent for your career and your pocketbook. It is impossible to meet a quota without it.

Saving that Face

Face-saving. As I learned when I worked in Asia, face-saving is prominent in Asian culture. And the term was used a lot when I worked there. But while I don’t support mean-spiritedness, people who make big claims turn out to be false need to own up to it and be exposed to wrong. If not, we would not have science. We would be more concerned about embarrassing people who were wrong and never make progress. To protect Stan’s face, we would continue to agree that the moon is made of green cheese.

This is presently a big problem in IT and IT forecasting. I like to say that the only thing anyone is held accountable for regarding prediction is meeting their sales quota. Gartner has quite a poor accuracy level in their forecasts.

They were responsible for priming the ERP bubble in the eighties.
The marketplace bubble in the late nineties.
They are currently pumping up the Big Data and analytics bubble as well as the IoT bubble.

But do you see Gartner paying a financial penalty for being the Helen Keller of IT forecasting? No, they are richer, more powerful, and more influential than ever.

Unfortunately, no entity calls out individuals or companies that knowingly distribute false information on IT topics. And this has lead to a bubble in buffoonery.

Diverting Attention from Previous False Statements

I have spent a good deal of time investigating the performance claims, and many other HANA DB claims. Here is what I have found.

The uniqueness of HANA’s performance has been explained in my previous articles as entirely manufactured by SAP. There was never any truth to it. The people that proposed this are diminished in my eyes for the lies that they told. At the tip of the lying spear is Dr. Hasso Plattner, but there are plenty of other culprits.
SAP has proposed that end of period close, and MRP use is held back by not having a database like HANA. This is false as neither process is a bottleneck for the vast majority of companies. If, as a company, you have a system processing constraint with either of these processes, you are in the distinct minority. Instead of moving to HANA, you should try to find lower-cost ways of figuring out the problem. As soon as a person raises either of these issues, I know that one of two things must be true. Either they know it’s incorrect but is willingly stating that these things are the case. Or secondly, and perhaps what can be more forgiven, they merely repeat what they read in some SAP marketing material. Let us discuss reasonable expectations. One should not expect account managers or partners who have never touched SAP in 10 years or been on an SAP project to be reliable sources of information on technology topics.

Backflushing is Performed Because of a Lack of Database Speed?

Recently SAP proposed that even backflushing is performed because of a lack of database speed. And that HANA was going to come to the rescue of all these poor companies that have had to perform backflushing because their ECC systems cannot perform goods issue due to system performance problems. This is truly ridiculous as backflushing moves the goods issue processing from real-time to be run in batch. Can SAP seriously think they can convince people that ECC sitting on a non-HANA database lacks the processing capability to perform something as simple as a goods issue in real time??

Backflushing has never been done (at least in the modern era) because of performance limitations. Backflushing is performed because the company wanted to carry out the activity first and record the issues after the fact. Backflushing is very common in process industry manufacturing. This is because it can often be unclear how much material will be consumed in the manufacturing process.

Diverting Attention

HANA proponents enjoy diverting the attention from the original topic. They gain the high ground by claiming other benefits from these other areas of “improvement.” A deflection mechanism is a consistent approach by those who have been consistently wrong on HANA. The algorithm looks like this:

Standard HANA DB Pitch: If you find an uninitiated audience, give the standard line about how HANA is revolutionary due to its speed. Hide the fact that other database vendors have the same technology. Pretend that you invented the idea that data can be stored in an SSD.
Dealing with Hecklers, Malcontents & People that Won’t Accept the Sales BS: If (on the rare occasion) you find an individual who knows this is not true, respond that HANA is much more than a database and about “much more than speed.” Do this even though you know that each item that is “not just a database” actually has their names like HANA Studio, HCP. And that these products have no logical reason to have the term HANA in their product name. And further, ignore that SAP’s first promotion of HANA DB has been based upon database speed.
Misdirection: Having regained the argumentative, high ground, now make false claims, but now in different areas. I call this maneuver the “Hasso Plattner.” Make so many claims in so many different areas that the person you are speaking to may not feel comfortable addressing them all. Force the respondent to perform research in many different areas to respond to your proposals. But you do not research at all! Simply repeat false statements provided to you by SAP marketing.
Use Project “Proof”: Bring up illusory benefits that you have seen at all these clients you have visited, where HANA is just transforming the way companies do business. This will also communicate to the LinkedIn community that you are a real expert in HANA. Don’t bring up any complications of HANA. And never discuss costs.
Employ the Concept of Universal Virtue: Talk about how you are all about improvements. And that these things are necessary to make these improvements. Promote the concept that both you and SAP are all about “client value.” One commenter states that SAP should be allowed “maximum forgiveness” for any false statements that it made. The reason? Because it was all about moving companies to a “fill in the blank” (digital economy), (memory resident future), (IoT), (running simple),(integrated solutions).

Massive Exaggerations

Suppose SAP has massively exaggerated the issue of HANA DB performance. Both of the perspectives of the performance itself and the application or business case for that performance. Then that is a problem. It is not an adequate or honest response to respond to this particular criticism with a comment related to how HANA DB is “more than a database.”

That only starts up another discussion. It may or may not be, but the statement I made is regarding HANA’s performance and value. That statement needs to be answered without diverting into other areas because one can’t respond to the actual question with convincing evidence.

SAP’s Official Position the Database

SAP’s official position is that HANA is a massive differentiator. So if SAP says something and it turns out to be false, then that is relevant.

Since HANA’s introduction, it has been a steady drumbeat from SAP to why the database is critical and why customers need to switch as soon as possible to HANA. ASUG’s position is that as SAP is the strategic vendor, those companies need to migrate to S/4HANA. There is no backing off of SAP’s emphasis on the database since SAP introduced HANA in 2011.

The Logic for Limiting S/4HANA to HANA

Let us also remember the logic for limiting S/4HANA to HANA — that no other database vendor can keep up with SAP’s innovation. SAP is restricting choice and doing so for purely commercial reasons, all while telling people it is for technical purposes. This entire storyline is false and is provable as false.

SAP’s Credibility Hit Due to HANA’s Claims Being Found to be False

If what is true is important, then this is a problem for this specific subject and companies that intend to listen to advice from either SAP or SAP consulting companies on other topics.

HANA’s Predicted TCO

Second, our research predicts that HANA will have a higher than 2x TCO versus competing databases. Again, SAP stated that HANA’s TCO would be lower — lower even than when HANA replaces an existing database and will implement faster than an already implemented database. The second sentence is impossible, and it should be obvious why. You don’t have to pay this extra TCO, but disrupting the database layer for what turns out to be negative reasons (that is, you are worse off as a company after you do it), but the customers do have to deal with this wasteful disruption. This means that SAP has been and will continue to misdirect IT budgets into HANA.

HANA’s Performance Problems with S/4HANA

A final reason to care about HANA, even within the context you mention, is that HANA has performance problems supporting ERP, as we covered in the article The Mismatch Between HANA and S/4HANA and ERP.

This fact alone means that S/4HANA’s value proposition is compromised. But once you include S/4HANA’s implementation history, how S/4HANA’s risk is so high, it is difficult to find a major application with higher risk right now.

The Issue with the Perceived “Importance” of the DB

We all tend to think that the “important thing” is whatever we happen to work in. I focus more on the application area myself. However, I am personally amazed by what databases can do. Databases are an amazing intellectual achievement. Once you spend time with a database person or developer who takes you through what is possible, they seem like magic. Non-database people tend to think in terms of spreadsheet tables with the tables just pointing to each other (as the ERD diagram).

However, that is a vastly oversimplified construct.

In many applications, people tend to see development as something not to focus attention on. They may say, “just give me the app.” I used to think that way myself. Better understanding development as I have in the past year or so leads one to question application design rather than accepting what is available. The current applications we have are just what someone thought made sense. They are not necessarily right or the best way to do things, and with development capability, you can make whatever you want, not what someone else thinks is right.

Taking Things for Granted

It is also easy to take things for granted once they have been mastered. Databases run far more smoothly than applications now, so it is easy to think that they are not as important.

It’s a bit like how often you think about your feet is how directly proportional to how good your shoes are. If you have good shoes, you do not think about your feet.

Understanding Pivot

It seems like there is a pattern that is established. It goes like this…

The first position is that SAP is 100% correct, and this is the future. The first presentations were that SAP had the best database globally with HANA, and everyone who did not switch to HANA was an idiot. Hasso Plattner had a popular blog post where he said those who question HANA’s value “just don’t get it.”
When faced with evidence that undermines SAP’s claim, there is a transition to saying that there are some “misunderstandings” about SAP.
When SAP is proven entirely wrong and or to have deliberately misled people, the topic area is not important anyway. Then the pivot happens to another topic, and new claims are made that, once investigated, are also false.

Using this strategy means that SAP is never held accountable for what they say.

Go to top

Conclusion

Getting quality IT information is a tricky business. There are many overconfident and dishonest people out there who will unthinkingly repeat false information and then defend their positions if questioned. They will try to sell the future. They will pretend they have seen benefits where they haven’t. They will use unproven arguments like a new application that no one has performed a TCO calculation on automatically lowers TCO. They will use ad-hominem attacks. They will rely on concepts that have been disproven long ago (best practices, preconfigured solutions, rapid deployment solutions).