- How SAP Uses the Term Legacy
- Legacy When Applied to Non-HANA Databases
- Ding Ding Ding!
- Other Claims
SAP has a long history of using the term legacy inaccurately. This is covered in the article How SAP Used and Abused the Term Legacy. However, SAP recently began using the term against non-HANA databases.
In this article, we will evaluate the accuracy of this usage.
The Statements About Legacy
This is from SAP’s website.
Here SAP proposes that all other databases are outdated technology. They also imply that only HANA has in-memory architecture and that it is revolutionary. We will address each of these claims.
This is where the term Legacy is used.
Evaluation of the Claims
First, SAP is a more recent database than IBM Blu, Oracle 12c, and Microsoft SQL Server. However, SAP is in no position to call any of these databases legacy. This is because these databases outperform HANA, as we cover in the article What is the Actual Performance of HANA?
Legacy means that the item is near obsolete.
This a ludicrous claim for any of these databases, all of which have many times more installations than HANA, and unlike HANA, all three of these other databases are used outside of SAP with non-SAP applications. SAP cannot claim this, which provides an inkling as to the competitiveness of HANA.
This claim is so exaggerated that….
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.
Now let us review the other claims made in the SAP statements.
- All other Databases are Outdated Technology?: That is an enormous claim. What evidence has SAP produced that this is true? Information coming back from actual projects indicate that HANA cannot keep up with the performance of previous generation databases outside of data warehouse type queries, (where it loses against the updated versions of these other databases). The details of this are covered in the article HANA as a Mismatch for S/4HANA and ERP.
- HANA has Revolutionary In-Memory Architecture: This claim is also false, as we cover in the article How to Understand Why In-Memory Computing is a Myth.
- 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.
- Only HANA Can Support High-Speed Analytics?: This is news to every database vendor that competes with SAP. All of these databases can support high-speed analytics. Again, HANA loses against its primary competitors in analytics, if those databases are the most up to date versions. The older version will lose against HANA in analytics because they lack the column-oriented store. SAP is continually attempting to have HANA compete against databases from vendors from six years ago when HANA was first introduced. Of course, HANA on new hardware will beat other databases on older hardware. Something that is quite obvious, but which is missed by IT departments that implement HANA on new hardware and discuss the improvements — without accounting for the percentage of performance which is solely due to the hardware. We covered this topic in the article How Much is Hardware Responsible for HANA’s Performance?
- Only HANA Has Application Services?: Application Services are a bit of a nebulous term. But they are applications. Oracle 12C, IBM Blu, and MS SQL Server run applications. Applications sit on top of them. Therefore, this is a curious way to differentiate HANA. This seems to imply that HANA is unique because it can interoperate with applications. If it couldn’t then what would it be doing?
- Only HANA has a Flexible Data Acquisition?: Why is that true? More flexible than competitive offerings? A database stores data. Data acquisition is normally performed by middleware. Of course, it depends upon the definition. If SAP’s definition of acquisition is that data can be loaded in different ways into the database, then again all of the competing databases have this ability.
- HANA has a Single Platform?: HANA is not a platform. HANA is a database. If SAP means that both the applications are offered by SAP as is the application — then this is true. But because SAP is not as good with databases as their competitors this also means that buyers of HANA give up specialization and many other factors to buy their application and database from the same vendor.
- Only HANA has no Data Duplication?: It is unclear why HANA offers less data duplication than competing databases. In fact, because of bizarre license restrictions, we are aware of scenarios where HANA has a 100% level of data duplication. This is explained in the article HANA Police and Indirect Access Charges. Here SAP requires companies buy a second license of HANA and replicate all data between the two HANA instances to allow data to be moved to a third database.
Literally nothing on this SAP webpage about HANA.
SAP receives a 1 out of 10 for accuracy on this proposals.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
The Real Story on ERP Book
How This Book is Structured
This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.
ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.
Break the Bank for ERP?
Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.
By reading this book you will:
- Examine the high failure rates of ERP implementations.
- Demystify the convincing arguments ERP vendors use to sell ERP.
- See how ERP vendors take control of client accounts with ERP.
- Understand why single-instance ERP is not typically feasible.
- Calculate the total cost of ownership and return on investment for your ERP implementation.
- Understand the alternatives to ERP.
- Chapter 1: Introduction to ERP Software
- Chapter 2: The History of ERP
- Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
- Chapter 4: The Best Practice Logic for ERP
- Chapter 5: The Integration Benefits Logic for ERP
- Chapter 6: Analyzing The Logic Used to Sell ERP
- Chapter 7: The High TCO and Low ROI of ERP
- Chapter 8: ERP and the Problem with Institutional Decision Making
- Chapter 9: How ERP Creates Redundant Systems
- Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
- Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
- Chapter 12: Conclusion