- Biased Information Source Says What About HANA?
- Issues Reported from the Field
- Changing the OEM Licensing Fee When Competition Arose
- Threats Against Customers for Not Using HANA
- How SAP Depreciates the Value of AnyDB
SAP has put tremendous marketing muscle behind HANA. What is nearly uncovered in the IT media is how SAP has used HANA to block out other database vendors from getting business on SAP projects. In this article, we will delve into this little-covered topic.
Issues Reported from the Field
SAP has become simply challenging to work with databases for all the competing vendors. In cases where the client wanted to maintain a simplified approach to running on the databases that they already had (non-SAP), SAP has denied access to database vendors for compatibility of specific components. However, before HANA, these types of coordinations between SAP and other database vendors was the norm.
It should be remembered that these customers already invested in competing database vendors, and by removing their cooperation with them, SAP is undermining the investment that their customers made into these databases.
Changing the OEM Licensing Fee When Competition Arose
SAP likes to present the idea that they are the only database vendor that has the capabilities of HANA. However, as we have covered in other articles, this is far from the case. Now IBM, Oracle, and Microsoft all have the ability to setup a column data store. And of course, they can use lots of memory (although no one has duplicated SAP’s approach of putting everything into memory, this is because it is wasteful).
As soon as SAP began to realize that the competing database vendors had excellent alternatives for precisely the capabilities that they had so promoted to customers, they then increased the SAP OEM ASL license fee for competing databases. This was increased from 8% of SAV (SAP application value) to 15% to match the cost of HANA.
When a database is “OEMed” through SAP, this means that it is sold through SAP. The OEM Application Specific Licensing or OEM ASL is the cost of that item.
This includes the following:
- IBM: Increases for DB2 under the OEM ASL from 8% to 15% for new transactions.
- Oracle: Progressive increases for Oracle from 15 through 17, 19 to 21%+
- Microsoft: Here SAP behaved differently. SAP left the OEM ASL fee for SQL Server at 8%. This is because SAP knows full well these are smaller clients that have either SQL Server or lower cost alternative ERP options, where it’s easier relatively speaking for a small to medium business to switch ERP systems. Therefore, SAP changed the OEM ASL fee only for those customers that they felt they had locked in.
Prices of Competing Databases
It must be understood that this increased the price of competing databases when sold through SAP. This was an anti-competitive move designed to make HANA more competitive, but only by increasing the costs of the competing databases!
We have repeatedly covered the fact that HANA has the highest TCO of the competing databases. However, HANA not only increases the TCO for HANA, but for all the other databases that have been raised to match HANA! Now before HANA, SAP had no motivation to do this. But with HANA, they now have every motivation. SAP is intent on altering the playing field as much as possible to favor HANA.
Threats Against Customers for Not Using HANA
Customers that don’t choose HANA also incur SAP’s wrath. We are aware that considerable commercial pressure is placed on SAP Business Suite clients, in particular with alternative database solutions to adopt SAP HANA both via license royalty “trade in offerings” and or reduced SAP discounts or increased in direct audit activity if SAP HANA is not adopted.
The timing of this reduction in discount was just as they were about to start a proof of concept between a competing database and HANA. One SAP customer was convinced to migrate BW to HANA (appliance) from a competing database, only to discover after 3-4 months effort, a simple deployment of the competing database delivered greater or similar throughput with one-half of the RAM for a fraction of the TCO and disruption and risk and implemented in 6 weeks.
And what drove this decision? The technology of HANA? No, a change in the commercial terms on the part of SAP.
How SAP Depreciates the Value of AnyDB
The SAP HANA development teams and a message from the Hasso Plattner seek to depreciate the value of alternative AnyDB choices gradually. They do this by gradually restricting functional delivery and new application version enablement to HANA vs. AnyAnyDB before.
However, several years after HANA was introduced, other vendors also advanced their own column-oriented tables.
“In the meantime, database players like Oracle and Microsoft are offering their own in-memory switches while supporting the systems management and IT talent infrastructure most CIOs have built over the last few decades. So in a couple of years SAP may have to reverse source about database portability. SAP has already shared dates for continued support of the Oracle Database 12c in-memory switch and its Engineering Systems products like Exadata and the SPARC SuperCluster.”
Yet even in 2018, SAP continues to lie to prospects about the “uniqueness” of HANA. All while SAP knows that HANA underperforms other databases.
SAP is cheating to get as many HANA sales as possible. SAP does this in the shadows to keep its aggression towards competing databases from public view. SAP pretends that its HANA performance is superior to AnyDB, but that has been disproven through benchmarking and through reports from the field as is covered in the article What is the Actual Performance of HANA? What SAP won’t talk about is how it uses both commercial terms and a lack of cooperations with AnyDB vendors. What SAP cannot do is create a competitive database (at least not yet), however, what SAP can do is take the low road in blocking out other database vendors and increase the overall costs of other databases that it resells.
For every sale that SAP makes for HANA the pretense given to other customers and to Wall Street is that the database was selected because the customer freely chose it. However, under the covers, in many cases, the customers have been coerced into purchasing it.
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 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