How Accurate is SAP on Only HANA Being an ACID Database?

Executive Summary

  • SAP proposes that the fact HANA is an ACID compliant database is a new thing for databases.
  • SAP is attempting to trick customers regarding fundamental concepts regarding databases.

Introduction

SAP has a long history of using the terms inaccurately and they essentially never get called out in IT media outlets. In this article, we will evaluate the accuracy of this usage of something called ACID for databases.

The Statements About HANA and ACID Compliance

This is from SAP’s website.

ACID Compliance?

ACID stands for (Atomicity, Consistency, Isolation, Durability). They are fundamental requirements of a database.

Every single one of the databases that HANA competes with is ACID compliant! And they have been for decades. This is tantamount to General Motors saying that its cars are better than competitors because they use spark plugs.

Why would SAP say such a thing? Most likely because their readers do not know what ACID compliance is, and therefore they think it is some type of differentiator.

Ding Ding Ding!

We award SAP a Golden Pinocchio for making this proposal.

The comment is so divorced from reality and so false that there is no other conclusion than to say SAP is undoubtedly aware they are deceiving readers by publishing these statements.

Conclusion

This is one of many statements meant to deceive readers about HANA. HANA is ACID compliant, but none of SAP’s competitors aren’t, and ACID stopped being an area of competition in databases decades ago. SAP goes further to imply that only HANA is ACID compliant. It depends upon the reading, but it is certainly intended to make it appear as if it is a differentiator.

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 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 Accuracy on HANA Content

References

https://www.sap.com/cmp/ppc/crm-xm16-gam-it-bd/index.html

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

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.

Chapters

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