Did SAP Simply Reinvent the Wheel with HANA?
Executive Summary
- SAP made many claims about HANA, but what SAP did with HANA is reinventing the wheel upon analysis.
- We cover SAP proposals ranging from code pushdown to in-memory computing to the fictitious backstory for HANA.
Video Introduction: HANA as a Derivative Product
Text Introduction (Skip if You Watched the Video)
Innovation has been a critical selling point of HANA. However, this has been based upon false claims by SAP, as all that HANA is, has been reverse-engineered by SAP from other databases. This fiction has been maintained by not only SAP but by SAP consulting firms and IT media. These companies have an undeclared financial bias, and IT media is paid by SAP to carry their marketing material. We review the claims of innovation in HANA and compare these claims to pre-existing functionality in other applications. You will learn how accurate are the claims around SAP claims for innovation.
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.
Understanding SAP’s History with HANA
When SAP first introduced HANA, which was begun with enormous fanfare, the idea was that SAP had created a whole new database. In fact, as recent as the Q4 2017 analyst call, Bill McDermott stated the following:
“Back in 2010, we set bold ambitions for SAP. We focused on our customers to be a truly global business software market leader. We set out to reinvent the database industry.
Forrester has now defined the new market for translitical data platforms, and of course, they ranked SAP HANA as the clear number one. We led the market with intelligent ERP, built on an in-memory architecture.”
This article will analyze how much of what SAP created with HANA is new and how much is simply copied from other database vendors and then claimed as innovation.
Important Information About HANA
We have performed an extensive detailed analysis of HANA. The more we look, the less we can find that is unique or innovative.
Let us review some of the major points of inconsistencies with the innovation story around HANA.
The Performance of HANA
SAP has vociferously proposed that HANA is faster than any other database. However, they have provided no evidence that this is true. We performed the necessary research into this topic and concluded that SAP’s claims of superiority versus Oracle, IBM, and Microsoft’s competing offerings are untrue. We have explained this in the article What is the Actual Performance of S/4HANA?
The Column Oriented Design of HANA
SAP has proposed that they essentially invented column-oriented databases. Column-Oriented databases go back as far as row oriented (often referred to as relational), and SAP acquired Sybase in 2010 before SAP introduced HANA. And Sybase already had IQ, now SAP IQ, that is was a column-oriented database.
Furthermore, SAP made other acquisitions very silently to give the impression that they “invented” the technologies that underpin HANA. At the same time, SAP’s marketing documentation was intended to provide prospects that SAP had invented a new category of databases. Notice Bill McDermott’s statement around “reinventing the database industry.”
That is reinventing it with a database design that had been around for decades? Furthermore, this comment was not made in 2011 or 2013 when HANA had yet to be challenged. This comment was made in 2018 after plenty of time has passed to verify HANA’s marketing statements with both real implementations, benchmarking, and the HANA technical documentation.
SAP has a long history of faking innovation. Faking innovation is a major strategy in both software and patent drug industries, which covers a process whereby innovations are taken from the public domain (or from competitors) and repackaged as something developed internally.
Calling All New HANA Development “Innovations”
SAP has claimed that because HANA is actively developed, that each development is innovation.
Yet, the items that HANA is developing already exist in other databases. The definition of innovation is that the item needs to be new. Not new to the software vendor, but new to the world.
While not discussed, innovation should also be beneficial. Areas where SAP has done things that are new, such as reducing aggregates, have not been demonstrated to be helpful. Reducing database size is an issue if a company is somehow constrained in its databases, but with the meager cost of modern storage, this is not the case.
SAP has proposed through surrogates like John Appleby of Bluefin Solutions that hard disks “take up a lot of space” and that companies cannot afford the storage space to locate disks – which is either absurd or insulting depending upon your perspective. One has to question the innovation of any company that has a spokesman like John Appleby (which we cover in the article Why John Appleby Was so Wrong About His HANA Predictions), Vishal Sikka, or Hasso Plattner that are repeatedly found in hindsight to have knowingly released false information into the marketplace. It is usually the case that genuinely innovative entities do not find it necessary to lie about their innovations.
SAP uses terms for propagandistic effect more than any vendor that we study at Brightwork Research & Analysis. Using words for propaganda means that the word has no other purpose other than to mislead the audience..
HANA and Innovation?
In the article How HANA 2 Was a Cover Story for the Real Story, we covered how SAP repeatedly used the term innovation as cover because something very undesirable occurred with HANA 2. Something that customers of earlier versions of HANA would have never imagined they would have to deal with. HANA 2 was not backward compatible with HANA 1 SPS 9 and below.
“What is really changing is SAP enabling customers to choose how they manage their update cycles. Currently, SAP releases a new SPS pack for HANA every 6 months and expect customers to be within 2 SPS levels as part of the terms of their maintenance contract. For some organisations this rate of change is just too much but something they have to manage to retain support, meaning those organisations often have to live with the constant change – this constant change of their core landscape can often kill innovation. – AgilityWorks
Research at Brightwork into HANA indicates that SAP and their surrogates use the term “innovation” to simplify development. HANA is behind its competitors and is developing more rapidly to catch up. But the correct word for this is not innovation. Here is the definition of innovation.
But the correct word for this is not innovation. Here is the definition of innovation.
Innovation Used to Excuse Database Instability
Another primary use of the term innovation by SAP has been to serve as a cover for product immaturity. SAP has repeatedly talked about how customers would receive “rapid innovations.” However, again, these areas, SAP is developing, are not new. They are new to HANA, but that does not make them new to databases in general.
SAP has been doing because HANA is not stable; SAP again brought out the trope of innovation. Therefore, the fact that SAP was “innovating” was why customers should not expect stability. The apparent fact that the same functionality is available from far more established database vendors that already have the same features and that also have stability is not observed by SAP or by consulting companies that advise companies on SAP.
The Code PushDown of HANA (Innovation or Innovative Terminology?)
A stored procedure is the established term when the code is moved from the application layer to the database layer, usually for performance reasons. However, SAP decided to come up with a new term, code pushdown.
Why?
Well, as our colleague points out.
“But by using the code pushdown term and not “stored procedures + DB views”, they not only have an innovative term for real “stored procedures” but also obscure that classic ABAP views are extremely far behind REAL Views that exist for decades and that this is one reason why the database is kept so stupid in classical “ERP on AnyDB”.”
This is why analyzing the terminology that SAP uses is so important. SAP uses specialized and often inaccurate terminology to lie to customers. This is found in the way SAP called HANA “in memory,” which we cover in the next section. When a false term is used, it is just the starting point. It can be considered the sound of a gate opening for what will be a torrent of incorrect information.
SAP’s presented logic for code pushdown is performance, but when SAP had no database to sell, they favored performing processing in the application layer. The code pushdown is what has served as justification for SAP to keep S/4HANA exclusive to HANA. That is curious. An ERP system with relatively low-performance requirements must have the code pushed down to the HANA database, but other applications that SAP offers that SAP has less account control over still work on AnyDB.
Here the apparent factor in determining which applications are exclusive to HANA and which do not have to do with leverage, not the technical requirements.
Oracle on SAP’s Code Push Down
In Oracle’s August 2019 paper Oracle for SAP Database Update, Oracle has the following to say on SAP’s innovation claim regarding code pushdown.
SAP used to think of a database as a dumb data store. Whenever a user wants to do something useful with the data, it must be transferred, because the intelligence sits in the SAP Application Server. The disadvantages of this approach are obvious: If the sum of 1 million values needs to be calculated and if those values represent money in different currencies, 1 million individual values are transferred from the database server to the application server – only to be thrown away after the calculation has been done. As a response to this insight, SAP developed the..
„Push down“ strategy: push down code that requires data-intensive computations from the application layer to the database layer. They developed a completely new programming model that allows ABAP code to (implicitly or explicitly) call procedures stored in the database. And they defined a library of standard procedures, called SAP NetWeaver Core Data Services (CDS).
20 years earlier, Oracle had already had the same idea and made the same decision. Since version 7 Oracle Database allows developers to create procedures and functions that can be stored and run within the database.(emphasis added) It was, therefore, possible to make CDS available for Oracle Database as well, and today SAP application developers can make use of it.
How can code pushdown be innovative if Oracle had been doing it 20 years before SAP?
The CDSs of HANA
Core Data Services are a type of code pushdown that is a database view. SAP has introduced CDSs as something new when copying the idea of the dictionaries that have been available in AnyDB databases for decades.
SAP has stated that AnyDB can also “use” CDSs, but the question is why they would want to do so. SAP is giving the impression that catching up with other database vendors is coming up with something new that does not already exist for the AnyDB database. Here again, SAP’s innovation claims do not pass the smell test.
Caching of Queries
In the document Boost Performance for CDS Views in SAP HANA, SAP states that it needs to cache queries for performance.
It further states:
“Keep CDS views simple (in particular serviceQuality A and B = #BASIC views)
In transactional processing, only use simple CDS views accessed via CDS key
Expose only required fields define associations to reach additional fields when requested”
This is odd. For an in-memory zero-latency database like HANA, why would these limitations need to be put into place?
“Perform expensive operations (e.g. calculated fields) after data reduction (filtering, aggregation)
Avoid joins and filters on calculated fields
Test performance of CDS views. Test with reasonable (= realistic) test data”
This speaks to the need to limit the consumption of computing resources. Again, it should not apply to HANA.
“Stay tuned on caching possibilities of SAP HANA and Fiori apps.”
Caching for Both HANA and Fiori?
Caching for both HANA and Fiori? Impossible! A foundational proposal of SAP since HANA was first introduced was that there should be no caching.
Everything, literally everything, is supposed to be in memory. Caching makes no sense with the presented HANA design. The people working at SAP on HANA and presented this at TechEd 2017 clearly do not understand Hasso’s vision.
According to Hasso Plattner, HANA is and forever will zero latency. The techniques described in the actual HANA technical documentation show a much more complicated picture with SAP performing caching in several locations.
Not only can HANA not provide zero latency (surprise, surprise). But testing even optimized demo boxes shows that Fiori running on HANA underperforms open source databases and server technologies like MySQL and Apache, as explained in the article Why is the Fiori Cloud so Slow?
Furthermore, the hardware specs that SAP has for HANA are extensive. The column-oriented store, combined with RAM’s vast quantities, is supposed to be so incredible that these types of techniques should not be necessary. But HANA underperforms other databases even though it has far more hardware. The Oracle benchmark shows that HANA could only come close to Oracle 12c performance with far more hardware. This is, of course, a benchmark produced by Oracle. However, other private benchmarks that have been made available to Brightwork show the same thing.
Everything In Memory and In-Memory Computing?
When SAP first introduced HANA, SAP stated that the database’s entirety would have to be loaded into memory. However, the technical documentation on HANA shows clearly that only some tables are loaded into memory. Neither the large tables nor the column-oriented tables are immediately loaded into memory. This is peculiar, as it was supposed to be the relationship between column-oriented and tables and high-speed memory to provide HANA with its analytical advantage. However, either way, HANA uses memory optimization….surprise, just as all of the other database vendors that SAP is copying its solution from. As we covered in the article How to Understand Why In-Memory Computing is a Myth, all databases have their tables placed into memory.
However, a database is much more than whether a larger percentage of the tables are placed into memory or whether it uses a column store for more of the tables. This is, by the way, another detail that has come to light as time has passed. Initially, SAP stated the entire database was a column store (which would not have made any sense, by the way), then it is determined that many of the tables in HANA are, in fact, rows.
Here again, one thing is stated about how HANA works, implying that all other database vendors are backward for memory optimization. Then once the technical details are read, HANA just does the same thing other databases do. This gets back to the central point that almost nothing that a salesperson or HANA marketing literature says about HANA can be trusted.
This article was published in March of 2018. However, in August of 2019, Oracle released a document called Oracle for SAP Database Update.
In this document, Oracle made the following statement about HANA versus Oracle.
Oracle Database 12c comes with a Database In-Memory option, however it is not an in-memory database. Support-ers of the in-memory database approach believe that a database should not be stored on disk, but (completely) in memory, and that all data should be stored in columnar format. It is easy to see that for several reasons (among them data persistency and data manipulation via OLTP applications) a pure in-memory database in this sense is not possible. Therefore, components and features not compatible with the original concept have silently been added to in-memory databases such as HANA.
Here Oracle is calling out SAP for lying. Furthermore, we agree with this. SAP’s proposal about placing all data into memory was always based upon ignorance and ignorance on the part of primarily Hasso Plattner.
If SAP had followed Oracle’s design approach, companies would not have to perform extensive code remediation — as we covered in the article SAP’s Advice on S/4HANA Code Remediation.
The Obvious Conclusion
Increasingly it merely appears that purchased some database products and then reverse engineered existing databases while putting an extra emphasis on placing more of the database in memory.
Innovation or Copying while Throwing in Confusing Terminology?
When discussing this topic with several other people investigating HANA, they gave the following insight to us.
They recreate the wheel as an octagon because anyWheel is round and then sell you a cycloid molded road to drive smoothly – but only on their roads.
What is Truly New in HANA?
It seems like a lot of this is just recreating the wheel, but with the blue SAP bow on top.
This is how Hasso Plattner, SAP, and SAP partners would like to present HANA’s genesis. Not as a series of technologies that SAP purchased more than a year before HANA’s development, not based upon databases that had been developed more than a decade before HANA, but as divine inspiration by Hasso and his brilliant PhDs. Hasso has repeatedly been referred to as a genius. A genius who “discovered” something that he directed SAP to purchase, and then after purchasing, immediately invented. This false storyline is laid out very carefully in the book The In Memory Revolution.
HANA, The Only Database With a Purpose Built Fictitious Backstory
In the article Did Hasso Plattner and His Ph.D. Students Invent HANA?, we uncovered (with some helpful hints from someone who reached out to us) that unlike what was stated by SAP and Hasso Plattner. And unlike what has been repeated ad nauseam by compliant IT media entities and SAP consulting partners, the underlying technology for HANA was purchased, not invented by SAP. Furthermore, Hasso Plattner and his Ph.D. students added nothing to these technologies except developing rather impractical ideas such as a database having no aggregates.
SAP did not innovate with HANA. Their primary contribution was to promote the idea of dual-purpose databases, a database that can equally perform transaction processes and perform analytics. Yet, there is no evidence that this strategy is worthwhile. While doing this, SAP has both massively overstated the benefits to such a design while at the same time glossing over all of the downsides to such a design, one of which being higher overhead. Furthermore, as we covered in the article HANA as a Mismatch for S/4HANA and ERP, it is clear that SAP has not mastered the ability to perform both OLTP and OLAP equally well from a single database.
Through four books, which are littered with falsehoods, and serve more as marketing collateral for HANA than “books” in the traditional sense “written” by Hasso Plattner, was meant to storm the consciousness of prospects with how amazing HANA would be. It is one of the first books written that describes the invention of something that had already been invented.
Ding Ding Ding!
SAP receives our Golden Pinocchio Award first to purchase the technologies underpin HANA, then reverse engineering other databases and call it innovation. HANA should be considered a case study in innovation fakery. Why is this not publicly known? Due to the partnership agreements that SAP maintains with other vendors, SAP prevents SAP from being called out for its innovation fakery by vendors that know but are censored due to their partnership agreement with SAP. The only entity that could cover this story would have to have complete independence from SAP, which also rules out IT media entities that cover SAP.
Conclusion
HANA is consistent with what is becoming an established history with SAP of exaggerating its innovations and making it appear that ideas and techniques it took from other places were developed inside SAP. HANA does not run 100,000 times faster than all competitive offerings (Bill McDermott). It is not an innovative database.
The primary thing that is innovative about HANA is that SAP tells customers that it is innovative. Once you look under the hood, what you have is a far less mature database than other offerings and a desire of SAP to push competitors out of “its” accounts by using a falsified storyline about how innovative HANA is to customers that are soft targets. That is, the less database knowledge prospects have, the more SAP can gain traction in those accounts by propagating huge disruptions to their customers while greatly increasing the TCO of the databases used by them.