The HANA Police and SAP Indirect Access Charges

ByShaun Snapp

Last Updated on February 7, 2017 by Shaun Snapp

Executive Summary

  • Information has been coming from many SAP customers on strange indirect access charges.
  • HANA is one area where SAP intends to pursue indirect access claims aggressively.

Introduction to the SAP HANA Police

HANA has been subject to one of the most expensive media campaigns in the history of any enterprise software vendor. More evidence is coming to light as to why SAP wants its customers to purchase HANA so badly. This is because HANA puts SAP in the catbird seat for account control of its clients. Let us get into the why SAP wants HANA in accounts so badly and how it fits into SAP’s strategy of account control.

Information From Actual Accounts on Strange SAP Indirect Access Charges

Indirect access is when a software vendor charges a company to connect to its system. The fundamentals of indirect access or IA are covered in the article How to Best Understand Type 1 Versus Type 2 Indirect Access. SAP customers do not typically find out about indirect access restrictions during the sales process. Indirect access is presented as if it is copyright protected, but the way it is often treated by SAP, it is an enlargement of copyright protection.

Moreover, almost undiscussed in a published form, indirect access is used by large vendors to block out smaller vendors. Indirect access is, therefore, a kind of account control. Moreover, like any technique of account, control, indirect access is designed to point as many IT expenditures as possible back to the large IT vendor.

I do not know any of the smaller vendors that try to pull indirect access over on their customers. SAP is setting precedents that other vendors on the same client begin to ponder.

Once a customer buys HANA, the other database vendor learns of what SAP’s indirect access position. The other database vendor starts to think.

“What if I can get away with pulling indirect access on all the databases that I have already sold to the account!”

The Basis for Indirect Access in Law

It is essential to understand that SAP places indirect access rules that are not necessarily legally enforceable. SAP is enlarging the definition of indirect access to suit its purposes and hoping the indirect access cases are not taken to court, so they do not become part of the public record. Once part of the public record, they can be looked up by other companies, and then the cat is out of the bag.

Therefore, SAP essentially has a “bluffing position” when it comes to the law overall (on many topics actually), and indirect access is just another example of this.

SAP’s Inconsistency on Indirect Access

The inconsistency of SAP’s position on SAP indirect access is shown further in the scenario we are about to cover.

SAP is enforcing stringent and strange restrictions on what companies can do with the data in a HANA database. Do pay special attention to these terms laid out by SAP regarding extracting data from HANA.

  1. SAP’s position is that the client must use SAP Data Services.
  2. However, the use of SAP Data Services can be waived if the second instance of HANA is used, and the data is replicated to the second instance of HANA.

Let us review SAP’s graphic that shows how HANA is to connect to Hadoop using their adapter called Vora. Hadoop and Spark are their own vibrant open source ecosystem that anyone can try on AWS or Google Cloud (Google offers two flavors actually, Cloud DataProc and Cloud Dataflow, which is easier to use and is self-configuring). But SAP had plans to get into this market. They had been promoting how much they are involved in Big Data. However, we can see a problem immediately looking at just one graphic.

Ordinarily, an adapter like Vora, will connect one database to another. However, notice Vora first connects HANA for the ERP system to another HANA instance. Then Vora connects to Hadoop. Why? Hadoop is its own very widely used Big Data store with a full complement of open source tools. Why can’t the HANA application database (or enterprise data as shown in the graph) be copied to Hadoop? The reason is not technical, but because SAP’s license for HANA forbids it. Hence the need for the second copy of HANA. 

Let us look at another graphic, this time from the MAPR website.

Once again, the data coming from SCM (SAP) goes to HANA, to MAPR. But the sensor and social media data (which is not from SAP, goes directly to MAPR. What is the benefit of HANA in this design? (SAP makes several proposals, but non-SAP projects are pleased with 100% open source Hadoop) However, if the ERP, ECM, CRM (SAP) data is in Oracle, it can go directly to MAPR. However, if any application sits on HANA, it must then go through a second HANA database due to indirect access rules enforced by SAP. 

A few questions naturally arise.

  1. Why is the second instance of HANA required?
  2. If HANA cannot be technically or from a licensing perspective have data extracted from it, why does a purchase of a second HANA database change that fact?
  3. What are the cost implications of all of this?
  4. What about the database that may be on the receiving end of this data? As it is assumed, SAP would allow the data to be moved to another HANA instance, does this also serve to box out the other database vendor that is receiving the data?

The Great Limitations on HANA’s Flexibility and Usage

If a company buys HANA, it will be a big surprise to them that they cannot access it as a regular database. This means that customers need clarity on what the restrictions are on HANA before they purchase HANA.

A copy of HANA will, unless the database is tiny, be quite expensive. SAP offers that the client can use SAP Data Services, but what if the customer does like want to buy SAP Data Services? SAP has a poor history providing integration tools. SAP’s primary integration product is SAP XI/PI. It is rare even to see SAP XI/PI on projects now, and the application not considered competitive with other ETL tools.

Now, I have not used SAP Data Service, but in this regard, I am in good company. Based on this history, it is improbable that it will be of good enough quality to justify purchasing it. Moreover, SAP should not dictate which integration products SAP customers to buy, based upon looney rules with little legal merit on removing data from SAP’s database.

More HANA Means More Restrictions

This much is clear.

SAP wants to use restrictions to push everything over to more SAP products.

  • By tying S/4 to HANA, they currently restrict S/4 to HANA.
  • Once they have HANA at a customer, they want to dictate the integration product of SAP Data Services because HANA is used.

SAP is clearly showing what its real intent is with HANA. The talk may be all about benefits, TCO (which is a ridiculous proposal), and future directions, but what is undiscussed is how HANA allows SAP to apply more SAP indirect access rules to the data layer.

This means that the costs of HANA are far more than merely the cost of purchasing, implementing, and maintaining HANA. There is all manner of SAP indirect access cost implications.

Teradata seems to agree with this. In their complaint filed in court against SAP, they stated the following:

“SAP has carried out its plan through a previously undisclosed change to its long-standing sales practices that leaves its locked-in Top-Tier ERP Applications customers with little choice but to adoptHANA to the exclusion of Teradata’s EDAW products: tying upgrades of customers’ ERP Applications to customers’ adoption of HANA (while ending support for older versions of ERP Applications). On information and belief, SAP has also begun significantly restricting Teradata’s ability to access customers’ SAP ERP data stored in HANA (which is necessary for the functional use of Teradata’s EDAW products), thereby ensuring the success of its tying arrangement (emphasis added) in coercing customers to adopt HANA.”

“SAP first carried out this plan by tying (emphasis added) SAP ERP upgrades to the adoption of HANA. Specifically, SAP launched the latest version of its ERP Application, SAP S/4HANA, in February 2015. SAP describes S/4HANA as being “built on” and “natively written” for HANA. This marketing language attempts to conceal the fact that, in an abrupt change to past practice, SAP S/4HANA is wholly incompatible with other transactional databases and can only run on HANA. Thus, in order to upgrade to SAP’s newest ERP Application, customers must now also adopt HANA.”

“SAP’s Top-Tier ERP Applications (the tying product)(emphasis added) are a separate and distinct product and market from the market for SAP’s HANA product (the tied product)(emphasis added) and the overall market for EDAW products for SAP Top-Tier ERP Applications, including Teradata EDAW”

“SAP’s unlawful tying (emphasis added) is economically irrational conduct that has no legitimate business justification and only serves to foreclose competition in the EDAW Market for SAP’s Top-Tier ERP Applications customers. Any justification SAP could offer is either pretextual or is else far outweighed by the anticompetitive effects.

By reason of the foregoing, SAP’s arrangements with its current Top-Tier ERP Applications customers constitute unlawful agreements or combinations in restraint of trade, in violation of Section 1 of the Sherman Act, 15 U.S.C. § 1, and Section 3 of the Clayton Act, 15 24 U.S.C. § 14.”

“SAP’s tying(emphasis added) is per se unlawful given the high degree of market power SAP possesses in the market for Top-Tier ERP Applications and the power it exercises over its current Top-Tier ERP Applications customers. Competition in the EDAW Market has been and is appreciably restrained as a consequence of SAP’s conduct.”

“Alternatively, even if SAP’s tying is not a per se violation, SAP’s tying unreasonably restrains competition in the tied (emphasis added) product market and constitutes a rule of reason violation of Section 1 of the Sherman Act, 15 U.S.C. § 1, and Section 3 of the Clayton Act, 15 U.S.C. § 14. SAP’s conduct affects far more than a not insubstantial amount of commerce in the EDAW Market. The amount of business affected by SAP’s tying arrangement (emphasis added) is in the millions and will only continue to increase. Teradata has been harmed and will continue to suffer irreparable harm as a consequence of SAP’s conduct. Teradata is entitled to an injunction restraining SAP from engaging in the unlawful tying of upgrades to its ERP Applications with HANA. Unless and until SAP is enjoined, SAP will continue to engage in the unlawful tying (emphasis added) set forth above.”

A Company’s Options

Buying SAP Data Services is probably not a very good option for companies. However, if companies do not buy SAP Data Services, will they want to go the expensive route of buying another HANA instance? Consider, if the company keeps the SAP application on a non-HANA database, it does not have to replicate the data to another database or buy SAP Data Services. Therefore, but moving to HANA, the company’s options narrow, and the costs dramatically increase. This is interesting because SAP has made so much about HANA, reducing TCO. In this scenario, it seems like the TCO can only go up.

The fact that the second license of HANA renders a purchase of SAP Data Services unnecessary completely undermines any SAP indirect access argument. Let us think this through.

How can SAP indirect access apply, but if a second HANA database is obtained, then SAP indirect access does not apply?

Say what SAP?

Go to top

Conclusion

HANA is part of an overarching strategy to infiltrate the database layer with all kinds of SAP products. It all starts with the falsehood that no other database on the planet can match HANA’s performance, which our research and benchmarking have invalidated as we covered in the article What is the Actual Performance of HANA? and in the article How Much of HANA Performance is Hardware? This lie is repeated most vociferously by people who know the least about databases. Many people who have never touched a database in their life and who work in a sales capacity like to repeat statements from SAP marketing literature.

The argument to be made is that only SAP database products work with SAP. This scenario is just an extension of this strategy, which is to put in some additional license restrictions (potentially) that again drive more money to SAP products.

  • The textbook case of SAP indirect access is where a front-end is used to access data sitting that was generated by a SAP application. Since users are now accessing the data, but not through SAP, SAP is “being cheated out” of license revenues.
  • However, companies usually do not do this. They typically don’t create full applications to connect to SAP data. That is, they do not often engage in what is called two-way communication with the data. Instead, they with far higher frequency pull data from SAP (that is one-way communication). They create reports that use SAP data. However, it is hard to say that creating a report using SAP data that can be shared outside of the named user licenses is “using” the application.

Should Exporting Data from SAP Also be Covered Under a Different License?

People have been exporting data from SAP for time immemorial. The reason being that SAP has never had proper reporting tools within their applications, and it is tough to compete with a spreadsheet. Even with Tableau on the scene, which has excellent report building capability, it is rare to see Tableau up on people’s computers. Instead of Tableau, I see good old fashioned Excel. For all of its press, Tableau often becomes a toy for IT, which allows them to build up their resume, but which usually ends up being little used by the actual business.

Under the SAP indirect access logic, every single export into a spreadsheet is also cheating SAP out of revenues. Alternatively, for Microsoft, if I create a spreadsheet in Excel, and then export the data to a CSV file, which I then send to someone who opens it in a text editor, I am performing indirect access to Excel.

Moreover, this logic brings up an even weirder foundational assumption — which is that SAP owns your data and that you need to pay a toll every time you access it through a non-SAP system. Who would buy an application or database under those conditions?

Secondly, as this is a relatively recent concept, companies bought their SAP systems under one set of assumptions, only to have SAP introduce indirect access after the fact, changing the rules of systems that have already been purchased.

References

https://www.asugnews.com/article/sap-customers-sound-off-on-indirect-access-fees

https://www.linkedin.com/pulse/dealing-surprise-sap-license-charges-indirect-access-shaun-snapp

https://assets.teradata.com/News/2018/2018-06-19-Complaint.pdf

https://blogs.sap.com/2016/09/22/what-is-vora-and-how-it-helps-to-bridge-the-gap-between-enterprise-data-and-big-data/

https://www.opencore.com/blog/2017/5/sap-vora-introduction/