How Accurate Was John Appleby on HANA FAQ?

Executive Summary

  • John Appleby made bold predictions on HANA.
  • We review how accurate he was in his article on HANA FAQ.

Introduction

John Appleby’s article on the SAP HANA blog was titled The SAP HANA FAQ and was published on September 9, 2014.

The Quotations

HANA Performance

SAP HANA is an in-memory database and application platform, which is for many operations 10-1000x faster than a regular database like Oracle on the same hardware. This allows simplification of design and operations, as well as real-time business applications. Customers can finally begin to reduce IT complexity by removing the need for separate and multiple Application Servers, Operational Data Stores, Datamarts and complex BI Tool implementations.

HANA loads more data into memory and uses a high hardware specification with lots of memory, but HANA did not and still does not load all data into memory as we covered in How to Understand the In Memory Myth. 

HANA did not and does not run 10 to 1000x faster than a “regular database like Oracle.” Since this article was written Oracle added a column-oriented store which Bloor Research covered in the article How Accurate with Bloor Research on Oracle In Memory?

The data points we have indicate that HANA runs slower than Oracle, DB2 or most likely SQL Server. Such a claim made by Appleby here in 2014 is quite ridiculous as SAP had only been developing HANA (based upon TREX and P*Time, possibly some IP from Sybase and according to Teradata, their technology) for a few years. Such a claim of on average 500x faster is an enormously bold claim, although very small compared to Bill McDermott’s claims of a speed increase of 100,000 times as we covered in How Accurate Was SAP About HANA Being 100,000x Faster Than Any Other Technology in the World?

Appleby gets another Golden Pinocchio Award for this false claim regarding HANA’s performance. The award is shared with SAP, because Appleby would only make this claim with the approval of SAP. 

HANA does not reduce complexity, but because of its high overhead increases complexity. HANA is the highest maintenance database in the RDBMS category that we cover.

HANA is a Reinvention of “the” Database?

“SAP HANA is a “reinvention” of the database, based on 30 years of technology improvements, research and development. It allows the build of applications that are not possible on traditional RDBMS, and the renewal of existing applications like the SAP Business Suite.”

HANA is not a reinvention of the database. HANA is simply a multimodel database that can use column-oriented tables. SAP and Appleby should know as SAP acquired Sybase, which had Sybase IQ, which was a column-oriented design for more than a decade prior to SAP acquiring Sybase in 2010. The column-oriented design goes back to the 1970s, and was developed at the same time as the row-oriented database.

Why Was HANA Developed?

SAP co-founder and Chairman Hasso Plattner believed that if a database could be built with a zero response time, that business applications would be written fundamentally differently – and IT landscapes could be simplified. The research institution at the Hasso Plattner Institution in Potsdam theorized that with modern computers and software design, this would be very nearly possible.

It’s difficult to say if Hasso ever believed this. He said he did, and he might have.

He has repeatedly corroborated this, but if he did believe it, then Hasso had a great lack of knowledge on the subject. Secondly, zero latency cannot be stated without consideration for the load. Is it zero latency at infinite load?

Hasso has repeatedly stated that zero latency databases mean that coding is cut in half as he does in the following video.

It is never explained why coding is reduced simply because or if the database becomes zero latency. 

Hasso wins our Golden Pinocchio Award for both his statement regarding HANA being zero latency (it isn’t) and that a zero latency will reduce coding by 1/2 (it won’t). 

Only SAP Could Develop This?

“SAP makes business applications and since it was clear that none of the incumbent software vendors like Oracle would write such a database and application platform, they needed to build their own. In addition, this would be the springboard for a complete renewal and simplifying of SAP’s applications to take them through the next 20 years.”

Oracle and IBM and many other database vendors have far more database knowledge than did SAP. SAP picked up Sybase in 2010, but it now appears was not able to leverage the knowledge from Sybase employees to much of a degree.

It is also unclear why none of the incumbent software vendors could write such a database? They have more appropriate resources to do so than does and would be incentivized to do so. In fact, later IBM added dual mode capabilities to their database in Feb 2014, Oracle did so in July of 2013, and Microsoft did so in June of 2016. The problem is that there is little benefit to a database with this design.

Notice the timeline below.

HANA does not simplify applications. We covered the fact that HANA does not produce a simplified data model in the article How Accurate Was SAP About S/4HANA and a Simplified Data Model?

Furthermore, HANA increases complexity because of its overhead.

John Appleby gets a second Golden Pinocchio Award for his statement that no other database vendor could have created a database with a column store — as it had already been done when his article was published, and he would have known this. 

Is HANA Just a Database?

No. When SAP went to build HANA, they realized that the next generation of business applications would require a much more integrated approach than in the past.

SAP HANA contains – out of the box – the building blocks for entire enterprise applications. HANA can take care of the requirements that would be served by many layers in other application platforms, including transactional databases, reporting databases, integration layers, search, predictive and web. All of this is served up working out the box, with a single installation.

HANA is just a database. We covered this in the article How to Deflect That You Were Wrong About HANA.

HANA does not support the next generation of business applications. This is entirely hyperbole. We analyzed this claim which has been repeatedly made by Hasso Plattner in the article Is SAP S/4 HANA a New Application Architecture?

Why are the applications now more integrated than in the past? This is also not explained.

HANA does not contain building blocks for entire enterprise applications. HANA takes care of no layers in other applications platforms, and secondly, HANA is not an application platform. Good evidence of this is that since Appleby’s article was written and 2019, the number of applications written for HANA has been tiny.

This is entirely false, and it is misleading and deceptive in at least four different dimensions.

Appleby wins his third Golden Pinocchio award with this proposal about how HANA will bring in a new age in applications because HANA is a development platform, and with that, becomes the all-time leader for Golden Pinocchios in a single article. At least at the time this article was written. 

Where Does SAP HANA Come From?

SAP built SAP HANA from the ground up, including research from the Hasso Plattner Institute in Potsdam, the acquisition of the IP from the p*Time database, the TREX search engine, BWA in-memory appliance and MaxDB relational database. It has been extended with intellectual property from the Business Objects and Sybase acquisitions with products like Sybase IQ and Business Objects Data Federator.

Whilst HANA has a legacy and some code from other products, the bulk of the database and platform has been written from the ground up.

This is actually true.

In fact, here Appleby observes the importance of two acquisitions that were deemphasized in the future by SAP and in the book The In-Memory Revolution, where Hasso recounts the story of the origin of HANA.

We covered this history and the fake backstory created by SAP and Hasso for HANA in the article Did Hasso Plattner and His Ph.D. Students Invent HANA?

Furthermore, Appleby credits IP from Sybase and Business Objects, which is rarely done in later years.

It is unclear what the term “ground up” really means. If a database uses components from (we count six products listed by Appleby) it is difficult to propose that the product was created from “the ground up.”

What Makes SAP HANA Fundamentally Different?

SAP HANA is different by design. It stores all data in-memory, in columnar format and compressed. Because HANA is so fast, sums, indexes, materialized views and aggregates are not required, and this can reduce the database footprint by 95%. Everything is calculated on-demand, on the fly, in main memory. This makes it possible for companies to run OLTP and analytics applications on the same instance at the same time, and to allow for any type of real-time, ad hoc queries and analyses.

On top of this SAP built solutions to all the problems of columnar databases, like concurrency (HANA uses MVCC) and row-level insert and update performance (HANA uses various mechanisms like a delta store).

No. HANA does not store all data memory. SAP repeatedly made this statement and it later turned out to not be true and is contradicted by SAP’s own documentation on HANA, we covered this in How to Understand the In-Memory Myth.

The footprint is not reduced by 95%. SAP has claimed as high as 97.5% smaller footprint, but both of these numbers are false. Case studies from HANA projects around the globe have reported roughly a 30% lower footprint. SAP will respond when they are challenged on this p0int that the customer needs to perform extensive archiving, which can be performed with any non-HANA database as well to reduce the footprint and is really just a response for being caught in a lie. Secondly, the compression of column-oriented databases is well known and it is nowhere close to 95%

This is no doubt becoming a bit tedious, but we have to make the awards for consistency. Appleby receives his fourth Golden Pinnochio Award for his claim regarding HANA’s reduced footprint. We covered in the article How to Understand S/4HANA and HANA Pricing, how SAP has tricked companies into buying less HANA than they need by proposing the smaller footprint, which is relevant for HANA as it is priced per GB. 

Various Database Items Are Unique to HANA?

If this wasn’t enough SAP added a bunch of engines inside HANA to provide virtual OLAP functionality, data virtualization, text analysis, search, geospatial, graph (will be available soon) and web. It supports open standards like REST, JSON, ODBO, MDX, ODBC and JDBC. There is as much functionality in there as a whole Oracle or IBM software stack, in one database.

Most databases offer a number of items like this. This is not at all unique to HANA. SAP’s proposal there is as much functionality in HANA as Oracle is particularly preposterous as Oracle has a massive amount of database functionality.

Yes, here we go again. Appleby receives his fifth Golden Pinocchio Award for stating the HANA has more functionality than Oracle and the whole Oracle software stack. The Oracle database is decades old, so the idea that HANA would have already surpassed it after roughly 4 years of development (at the time Appleby’s article was written) is truly absurd. 

What Kinds of Use Cases Does SAP HANA Support?

The first HANA deployments were all analytical use cases like Datamarts and Data Warehouses because the benefits are there right out the box. EDWs like SAP BW run like lightening with a simple database swap.

With a transactional application like Finance or Supply Chain, most things run a little better from a simple database swap (SAP claim 50% faster for their own core finance). The real benefits come when logic from the applications are optimized and pushed down to the database level, from simplification of the apps (SAP is building a simplified version of their Business Suite), or from ancillary benefits like real-time operational reporting, real-time supply chain management or real-time offer management.

Best of all, unlike the other database systems in the market, HANA supports all applications on the same instance of data at the same time. No more copying, transforming and re-organizing data all over the enterprise to meet the needs of different applications. HANA perfectly serves the needs of all applications with one “system of record” instance.

SAP have provided a Use Case Repository that catalogues the various use cases for HANA.

It is true that HANA more naturally works with data warehouses, but there is another reason for this. HANA is a database that is optimized for analytics. However, BW does not run any faster than competing databases. Again, SAP has no technological superiority, so there is no reason for it to run faster.

Secondly, not all applications or even all SAP applications will run on one instance of data. Each application will continue to have its own database instance. This concept has been a pipe dream of SAP and their proponents since HANA was introduced. And there is zero evidence that anything like this has occurred on HANA customers.

What SAP Applications Run on SAP HANA?

SAP CEO Bill McDermott said “HANA is attached to everything we have”.

Almost all the major SAP Applications now run on the SAP HANA platform. This includes the SAP Business Suite (ERP, CRM, PLM, SCM) and the SAP BW Data Warehouse.

The BI Suite including BusinessObjects Enterprise, Data Services and SAP Lumira are all designed to run on the HANA platform.

There are a set of Applications Powered by SAP HANA including SAP Accelerated Trade Promotion Planning, SAP Collection Insight, SAP Convergent Pricing Simulation, SAP Customer Engagement Intelligence, SAP Demand Signal Management, SAP Assurance and Compliance Software, SAP Liquidity Risk Management, SAP Operational Process Intelligence, and SAP Tax Declaration Framework for Brazil.

In addition, SAP runs much of its cloud portfolio on HANA, including the HANA Cloud Platform and SAP Business ByDesign. The Ariba and SuccessFactors apps are in the process of migration.

This shows how inaccurate Bill McDermott’s statements are. In 2014 HANA supported BW. S/4HANA was not introduced until Feb of 2015. HANA was certainly being prepared to support other applications, and it now supports more applications in 2019, however, the phrasing of “HANA is attached” is odd and deceptive, and is essentially a way for McDermott to exaggerated what HANA supported. Attached is not a term used in IT. An item either supports another item or it doesn’t.

Now on to Appleby’s statements.

  • CRM and PLM were dead applications in 2014, so there is just not enough coverage of either application in 2014 to verify this claim.
  • SCM or APO (sometimes SAP refers to ECC as SCM) support would have been extremely limited. As an APO consultant, I never heard of an APO module being ported to HANA, although DP would be the natural choice as DP is nearly identical to the BW in the Data Workbench. And it is certainly possible a few DP instances were ported to HANA, but it was extremely rare.

We can’t verify each and every item that are part of the applications listed, but the applications listed were very rarely implemented with HANA. In later years after Appleby’s article was written companies reached out to use on Trade Promotion Planning, where SAP argued that HANA was mandatory.

HANA could have been brought up in HANA Cloud Platform (now SAP Cloud) but it rarely has been. ByDesign was eventually ported to HANA. But the port made no sense and was primarily for PR purposes. ByDesign is purchased by the SMB market, which cannot afford HANA. Today there are almost no users on ByDesign with HANA. Ariba is still not ported to HANA even in 2019, and SuccessFactors may or may not be partially ported. SAP is playing word games on this topic as we covered in Did SAP Move SuccessFactors to HANA?

The Golden Pinocchio Awards are coming fast and furious at this point in the article. Appleby receives his sixth Pinocchio for his false statements that a number of SAP applications were already ported to HANA in 2014. These statements are truly completely false. 

What’s the Business Case for SAP HANA?

“We’ve built business cases for HANA deployments of all sizes and whilst they vary, there at a few common themes:

TCO Reduction. In many cases HANA has a lower TCO. It reduces hardware renewal costs, frees up valuable enterprise storage and mainframes and requires much less maintenance

Complexity to simplicity. HANA simplifies landscapes by using the same copy of data for multiple applications. Our implementations have shown that adding additional applications to a HANA dataset are very fast and easy, delivering business benefits quickly.

Differentiation. HANA’s performance, advanced analytics (Predictive, Geospatial, Text analytics) and simplicity often mean a business process can be changed to be differentiating compared to competitors. Customer scenarios like loyalty management, personalized recommendations and anything where speed or advanced analytics capabilities are differentiating are all candidates.

Risk Mitigation. Many customers know that in-memory technologies are changing the world and so want to put an application like SAP BW on HANA or LOB Datamarts as a first step, so they can react quickly for future business demands.”

It is interesting how Appleby does not show the cases that he “built” but just shows the conclusions. We analyzed his TCO “case” in the article How Accurate Was John Appleby on HANA TCO for Cloud vs On-Premises? and it is a TCO that excludes all maintenance costs and consulting costs. So we think we will skip taking Appleby’s word for TCO without seeing the actual document. And as we know Appleby does not have the ability to sit down long enough to create a TCO, we know that will never happen.

All of the topics related to Appleby’s false claims about HANA performance have already been discussed.

HANA not only does not mitigate risk, but it is also the riskiest implementation of any of the databases it completes with, easily exceeding the risk of far more mature and tested databases like DB2 or Oracle or SQL Server.

In memory, technologies are not changing the world presently, and are not changing the world today as we covered in the article How to Understand the In-Memory Myth.

Is SAP HANA a Database, Platform, Appliance, or Cloud?

“SAP HANA was designed to be a truly modern database platform, and as a result the answer is: all of the above. A modern database should be a database, platform and be available on-premise or in the cloud.

SAP has a large installed-base of on premise ERP customers, and the HANA platform supports their needs, especially the need for an enterprise-class database. Many of those customers are looking for an on-premise database to replace the traditional RDBMS.

The demanding needs of an in-memory database mean that SAP elected to sell SAP HANA as an appliance, and it comes pre-packaged by the major hardware vendors as a result.

However the future of business is moving into the cloud, and SAP HANA is available as Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) with HANA Cloud Platform and Managed Cloud as a Service (McaaS) with secured HANA Enterprise Cloud and via 3rd party cloud vendors. Customers can also choose Hybrid deployment model that combines on premise and cloud. More details on this are available here.”

HANA is a database and not any of the other things Appleby states that it is. This was a primary SAP marketing proposal for most of HANA’s existence, but SAP finally moved away from this and renamed HANA Cloud Platform to SAP Cloud and HANA Studio to SAP Studio.

As we have covered earlier in this article, DB2 and Oracle had already added column orientated capabilities by this time, and Appleby knew this, but Appleby is pretending that these additions had still not occurred.

HANA is not available and was not available as any of the things Appleby stated. HANA was available to be brought up in SAP Cloud, but few people ever did this for anything but testing, and even in 2019 HANA has minimal usage in the cloud and it is primarily an on-premises database.

How Does SAP HANA Compare to Oracle or IBM?

“SAP HANA was designed to be a replacement to Oracle or IBM databases, either for net new installations or for existing customers. In most cases it is possible to move off those databases easily, and gain reporting performance benefits out of the box. Then it is possible to adapt the software to contain functions that were not possible in the past.

All three of the major RDBMS vendors have released in-memory add-ins to their databases in the last year. All of them support taking an additional copy of data in an in-memory cache, or in IBM’s case columnar tables. All of them provide improved performance for custom data-marts. But make no mistake; caching data has been around for a long time, while an in-memory database platform to run transactions and analytics together in the same instance is a new innovation.

Traditional database caching solutions are similar to the GM and Ford response to hybrid cars – take their existing technology and bolt new technology to it. SAP HANA is more akin to Tesla, who rebuilt the car from the ground up based on a new paradigm.

And so HANA’s capabilities from a business application perspective are 3 years ahead in technology from what others have.”

HANA was designed to replace DB2 and Oracle on SAP customers. This is true.

Finally, Appleby admits what he had not admitted up to this point, that IBM and Oracle had added a column store capability to their applications, but then states that DB2 and Oracle are not in memory, but are caching data. Each database vendor will tend to say their approach is the better approach, but the problem is that SAP won’t back-up their claims and seems quite intent on dodging IBM and Oracle and SQL Server by not publishing any HANA benchmarking for anything but BW, and not allowing other vendors to publish benchmarking for BW against HANA. Therefore, neither Appleby nor SAP have anything to back-up their claims.

Then Appleby follows up by stating that IBM and Oracle essentially just pasted column store onto their databases. There is no reason to believe this is true, and IBM and Oracle did a better job of merging column and row-oriented capabilities — not that we even think this was a necessary item to add.

Finally, Appleby again states that HANA is 3 years ahead when this was also not true. We covered how incorrect this was when Gartner wrote something similar in the article How Gartner Got HANA So Wrong.

How is HANA licensed?

“SAP tried to keep licensing simple with HANA.

HANA is available in the Cloud as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and as an application platform (AaaS), and it is possible to buy all those options now, on a monthly basis, from the SAP Website.

For on-premise customers, HANA is licensed in one of two major ways:

First, is as a proportion of your Software Application value (SAV), just like you can license other databases from SAP. This could be for your whole estate, or for a specific product like BPC.

Second, is by the unit, which is 64GB of RAM. There are a few editions of HANA, depending on your need, that bundle other software and allow more, or less, restrictive usage. The pricing is tiered, depending on the number of units you buy, and accretive.

In all cases, HANA licensing includes a lot of functionality that you would pay extra for in other databases. For example, Dev, Test, HA, DR licensing are always included. And if you buy HANA Enterprise, you have access to all functionality at no additional cost – including Predictive Libraries, Spatial, Graph, OLAP, Integration and Web. HANA contains a huge amount of functionality that would require 20-30 different SKUs from Oracle.

For those customers who need the base functionality of HANA but not the bells and whistles, there is now a HANA Base Edition, on which you can add other functionality as required, at a lower cost point.”

Licensing for HANA is extremely complicated and deceptive, as we covered in the article How to Understand S/4HANA and HANA Pricing.

HANA has similarly opaque pricing to other SAP products, but its sizing makes it complicated to price.

HANA did offer various items like Geospacial capabilities, but other databases also come with additional items, and the extras that came with HANA were typically not used. They simply did not have very much value. The statement about requiring 20-30 different SKUs from Oracle is not true. Furthermore, customers have complained to us that there are also a number of components that are not included in the pricing of HANA, that customers find out after they have made their HANA purchase that they also must buy.

How Big can an SAP HANA Database Grow? Does it Scale?

“With current hardware, SAP HANA can scale up to 6TB for a single system, and can scale out to 112TB in a cluster, or more. There is no hard technical limit to the size of a HANA cluster. Higher configurations are tested and certified at customer sites.

We are currently working with 24TB single systems with SAP that we expect to see this year.

At Bluefin, we regularly work with 2-10TB of memory in a single HANA DB, and this is where we find most business cases make sense. Remember that a 10TB HANA appliance can store a vast amount of data (as much as 50-100TB from a traditional RDBMS due to HANA’s data compression capabilities); this could represent all the credit card transactions for a top 10 bank for 10 years or more.

In addition, we find that customers look to be more intelligent about how they tier data with an in-memory appliance. Once the HANA database grows past 2TB, it makes a lot of sense to use a cold store like Sybase IQ for slow-changing data.”

Customers can’t afford to scale HANA because it is exorbitant in cost. Therefore its scalability is far less important than Appleby is stating, although the database footprints Appleby is quoting is inconsistent with our customer examples. Appleby is talking about a very expensive database and memory combination. HANA is still very inefficient in addressing the massive memory footprints it works with.

The last part of the quote seems to contradict SAP’s position of loading everything but archival data into memory.

Is SAP HANA a Row- or Column-Oriented Database?

“SAP HANA stores data for processing primarily in columnar format. But unlike other columnar databases, HANA’s columnar store was designed from the beginning to be efficient for all databases operations (reads, writes, updates). In practice, 99% of the database tables in SAP ERP are columnar tables, including transactional and master data tables.

HANA can also store data in row format, but this is primarily used to store configuration information and queues – only scenarios for which the column store is specifically not suited. With HANA, data is stored once, in its most granular form, and aggregated on request. There is no hybrid row/column store, no duplication or replication of data between row and column stores – HANA stores the data in the column store only.”

No, and that is ridiculous. HANA is a mix of row and column-oriented tables, with a far higher percentage of row oriented tables than 1%. If this were not the case, HANA would not be able to support ERP system, something it continues to have a problem doing in any case as we covered in HANA as a Mismatch for S/4HANA and ERP. 

Does SAP HANA Require Indexes or Aggregates?

“Every column in SAP HANA is stored as an index, and therefore HANA has no need for separate primary indexes. Secondary indexes with multiple columns are possible and used for OLTP scenarios like the Business Suite. HANA will also self-generate helper indexes to ensure that multi-column joins are efficient.

It is almost never necessary to aggregate data in HANA in advance because HANA calculates so quickly. HANA processes at 3bn scans/sec/core and 20m aggregations/sec/core which means 360bn scans/sec and 2.5bn aggregations/sec on a typical 120-core appliance. As a result it is much more efficient to calculate the information you require on demand.”

Indexes drop if a database stores data in columns…..but many of HANA’s tables are rows based, therefore SAP would greatly miss out from having no indexes. Instead, SAP has chosen to recalculate indexes for rows. The idea of recalculating aggregates that don’t change is just a wasteful design. However, what Appleby is saying here is roughly true. The false part is that Appleby is presenting this very weak design as if it is revolutionary. We covered aggregates in the article Is Hasso Plattner and SAP Correct About Database Aggregates?

Is SAP HANA a Big Data Platform?

“Yes, although HANA is best suited to high-value data, because it keeps data mostly in-memory. When Big Data is low value (e.g. web logs), HANA is very well suited as the store for high-value aggregated information and applications. This could be an organization’s hot data, e.g., 4 months of financial information for quarterly reporting. Other sources could be used to store additional data; for example SAP IQ could store 13 months of financial data for annual reporting (warm data) and Hadoop could store >10 years of financial data for seasonal and long term trend analysis (cool data). Large volumes of data in both IQ and Hadoop can be analyzed in combination with data in HANA, so it is possible to process the data in HANA into full-text Google-style indexes without storing all the detail in HANA.”

No, it isn’t, and we can’t recount a single customer that is using HANA as a Big Data platform. Secondly, let us consider how illogical Appleby’s statement is. Why would you keep all Big Data in memory? Of course, you would not. Thirdly, HANA is priced per GB, and is the most expensive database that we believe exists. Given this, why would customers want to pile data into it?

After Appleby’s article was written, SAP tried to tell customers that (as they weren’t going to load Big Data into HANA) that they should connect to Hadoop using Vora (which was a commercial version of Spark, which was open source). However, Vora is now dead, as we cover in the article How Accurate is SAP on Vora?

The upshot is that in 2019, HANA still has no footprint in the Big Data space.

Is SAP HANA Enterprise Ready?

“Yes. From its inception, HANA was intended to be a mission-critical database.

SAP HANA always stores a copy of data on disk for persistence, so if the power goes out, it will load data back into memory when power is restored (generally on-demand, but this is configurable). It stores logs so a very low Recovery Point Objective is possible.

HANA also has inbuilt capabilities to replicate the data to standby systems, so in a cluster, you can have High Availability and in any configuration you can have a cluster for Disaster Recovery and Fault Tolerance for business continuity. Disaster Recovery can be configured at the storage-level (depending on vendor) and also at the database level, which is called system replication.

It’s worth noting that most customers implement either HA or DR for HANA. It is exceptionally easy to set up (DR takes just a few clicks) and most customers that invest in HANA find business continuity is important to them.

HANA has had constant changes and instability since its inception, but Appleby never lets any of this on in this or any other quotation. In 2019, with HANA making little progress toward meeting its design objectives, SAP fired a large contingent of its HANA development as we covered in the article SAP’s Layoffs and a Brightwork Warning on HANA.

HANA lags competing databases in HA, something that IBM and Oracle have many years of development supporting.

What Happens if the Power Goes Out?

“SAP HANA is a completely ACID-compliant database which is designed to have a low Recovery Point Objective (RPO). HANA writes savepoints to disk at frequent intervals, which contain a snapshot of what is in memory. In-between savepoints, HANA saves a log of each database change to a fast flash disk.

If the power goes out, HANA loads the last savepoint and then plays the logs back, to ensure consistency.”

This is true, but all databases in this category have been ACID compliant for decades. On several other occasions SAP has made it sound as if only HANA is an ACID compliant database as we covered in the article How Accurate is SAP on Only HANA Being an ACID Database?

What Hardware Does SAP HANA Run On?

“HANA appliances must be certified and come either as pre-built appliances from your vendor of choice or as a custom build using your storage and networks “Tailored Datacenter Integration” or TDI.

SAP maintain a list of certified hardware platforms which currently includes Cisco, Dell, Fujitsu, Hitachi, HP, Huawei, IBM (Lenovo), NEC and SGI, and is being extended all the time. Note that this list only contains the new “Ivy Bridge” appliances and not the older “Westmere” appliances.

The exact hardware and storage configuration varies depending on a vendor. Some use servers and other use blades, some used a SAN storage network whilst IBM uses local storage with the GPFS distributed file system. In our experience, all these variants work very well.

In addition you can buy HANA in the cloud from Amazon, SAP and various other outsource partners like T-Systems or EMC. In this case, you can either pay a monthly subscription fee including license, or use an existing Enterprise license “Bring Your Own License”.”

This is true. Many hardware vendors created HANA appliances.

However, this fact contains a very interesting story, because Cisco, Dell, Fujitsu, Hitachi, HP, Huawei, Lenovo, NEC and SGI all invested in making HANA appliances, in great part based upon the exaggerated claims made by SAP. None of these companies did their homework, and apparently were only focused on repeating inaccuracies from SAP. None of these vendors have seen many benefits from investing in their HANA appliances because HANA grew far more slowly than anticipated.

Huawei bet big on HANA and lost.

As for the comment about HANA on AWS, etc… HANA is still predominantly an on-premises database.

Conclusion

This article scores a 1.5 out of 10 for accuracy. The article is correct on some basics, but the article is highly misleading, and Appleby winning six Golden Pinocchio Awards is a record for any article we have ever critiqued.

SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos

Fact-Checking SAP’s HANA Information

This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.

SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA is a Platform
0%
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.
10%
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
0%
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.
0%
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.
0%
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.
0%
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.
0%
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.
0%
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.
0%
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.

Being Part of the Solution: What to Do About HANA

We can provide feedback from multiple HANA accounts that provide realistic information around HANA — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how companies end up paying for a database which is exorbitantly priced, exorbitantly expensive to implement and exorbitantly expensive to maintain. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

The major problem with companies that bought HANA is that they made the investment without seeking any entity independent of SAP. SAP does not pay Gartner and Forrester the amount of money that they do so these entities can be independent as we covered in the article How Accurate Was The Forrester HANA TCO Study?

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

Inaccurate Messaging on HANA as Communicated in SAP Consulting Firm Videos

For those interested in the accuracy level of information communicated by consulting firms on HANA, see our analysis of the following video by IBM. SAP consulting firms are unreliable sources of information about SAP and primarily serve to simply repeat what SAP says, without any concern for accuracy. The lying in this video is brazen and shows that as a matter of normal course, the consulting firms are happy to provide false information around SAP.

SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA runs more "in-memory" than other databases.
10%
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
HANA is orders of magnitude faster than other databases.
0%
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.
HANA runs faster because it does not use disks like other databases.
0%
Other databases also use SSDs in addition to disk.Why Did SAP Pivot the Explanation of HANA In Memory?
HANA holds "business data" and "UX data" and "mobile data" and "machine learning data" and "IoT data."
0%
HANA is not a unifying database. HANA is only a database that supports a particular application, it is not for supporting data lakes.
SRM and CRM are part of S/4HANA.
0%
SRM and CRM are not part of S/4HANA. They are separate and separately sold applications. SAP C/4HANA is not yet ready for sale. How Accurate Was Bluefin Solutions on C-4HANA?
Netweaver is critical as a platform and is related to HANA.
0%
Netweaver is not relevant for this discussion. Secondly Netweaver is not an efficient environment from which to develop.
HANA works with Business Objects
10%
It is very rare to even hear about HANA and Business Objects. There are few Buisness Objects implementations that use HANA.SAP Business Objects Rating
Leonardo is an important application on SAP accounts.
0%
Leonardo is dead, therefore its discussion here is both misleading and irrelevant.Our 2019 Observation: SAP Leonardo is Dead
IBM Watson is an important application on SAP accounts.
0%
Watson is dead, therefore its discussion here is both misleading and irrelevant.How IBM is Distracting from the Watson Failure to Sell More AI and Machine Learning
Digital Boardroom is an important application on SAP accounts.
0%
SAP Digital Boardroom is another SAP item that has never been implemented many places.

Financial Disclosure

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.

Search Our Other John Appleby Fact Checking Content

References

https://blogs.saphana.com/2014/09/09/the-sap-hana-faq/

TCO Book

 

TCO3

Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
  • Understand why you need to look at TCO and not just ROI when making your purchasing decision.
  • Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
  • Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
  • Learn why ERP systems are not a significant investment, based on their TCO.
  • Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
  • Appreciate the importance and cost-effectiveness of a TCO audit.
  • Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
Chapters
  • Chapter 1:  Introduction
  • Chapter 2:  The Basics of TCO
  • Chapter 3:  The State of Enterprise TCO
  • Chapter 4:  ERP: The Multi-Billion Dollar TCO Analysis Failure
  • Chapter 5:  The TCO Method Used by Software Decisions
  • Chapter 6:  Using TCO for Better Decision Making