- IBM has been tolerating SAP’s false statements around HANA for several years, most likely promoted by its SAP consulting practice to not fight back.
- IBM funded a realistic analysis of HANA by Bloor Research.
- SAP greatly oversimplifies how database memory is optimized.
After many years of SAP saying pretty much anything that it wanted without Oracle, IBM or Microsoft saying very much (outside of Larry Ellison), in June 2017, IBM and Oracle began to fight back publicly. This pushback will lead to HANA’s further decline as the competitors to HANA have held back due to partnerships with SAP that they preferred for years to not unsettle.
In this article, we will analyze IBM’s anti-HANA slides that it recently released.
HANA Equals Complexity, Cost & Disruption?
All three of these items are true and is covered by Brightwork in various articles.
- The complexity of HANA is covered in Does HANA Actually Have a Simplified Data Model?
- The costs of HANA have covered in the article The Secret to Not Talking About the Cost of HANA.
- The disruption of HANA is covered in the article How to Best Understand Bloor Research’s Article on HANA.
SAP’s Oversimplification of How Database Memory is Optimally Used
When SAP introduced HANA, it came out with a very oversimplified explanation of how it worked and how databases use memory. In SAP’s explanation, they had created a true innovation because the entire database was loaded into memory.
However, very few of a database’s tables are normally operated upon at one time. Therefore, moving all the tables into memory, which was a prime selling point of HANA is quite wasteful. And SAP’s database concepts lags other vendors because SAP is new at databases.
SAP HANA Performance?
SAP will not allow a true competition between DB2 Blu, SQL Server, and Oracle 12c. The reason is that SAP wants to sell HANA, as is covered in the article What is the Actual Performance of HANA?
Brightwork has performed some of the most independent research on HANA. And in our view, it is unlikely that HANA can compete in performance with the competition, that SAP has for years been saying it is so much better than. It also cannot compete regarding maintenance overhead.
SAP HANA The Right Choice for Big Data & IoT?
This is true. IBM is underplaying its hand in this slide. But SAP intends to use HANA to lock in its customers. This is covered in the article The HANA Police and Indirect Access Charges. SAP is a problematic vendor and fits for many new areas, such as Big Data and IoT, as these areas are based upon open standards.
IBM & Bloor’s HANA White Paper
While this paper is funded by IBM, it received one of Brightwork’s highest accuracy level estimates at 9.5. Customers should read this white paper, and Philip Howard did a fine job writing it. We covered in the article How to Best Understand Bloor Research’s Article on HANA.
For the first time publicly at least, IBM is pushing back on HANA. SAP exaggerated the benefits of HANA as is covered in the article When Articles Exaggerate the Benefits of HANA. SAP’s complaint surrogate network of consulting companies also repeated false information from SAP to their clients. SAP consultants that do not work for SAP have been exaggerating HANA’s benefits without having any evidence or even understanding HANA, or having the first-hand experience on projects where HANA was implemented. That is they have been repeating falsehoods presented to them by SAP.
SAP’s expectation was that IBM and Oracle should be quiet about HANA and value their partnership sufficiently so that SAP would be allowed to bring in an inferior solution and market it as superior to IBM and Oracle’s RDBMS offering.
IBM apparently finally had enough.
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
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 HANA Used to Block Out Other Databases Content
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model