The HANA Police and SAP Indirect Access Charges

ByShaun 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 severely. This is because HANA puts SAP in the catbird seat for account control of its clients. Let us understand 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 How to Best Understand Type 1 Versus Type 2 Indirect Access. SAP customers do not typically learn about indirect access restrictions during sales. Indirect access is presented as if it is copyright-protected, but the way SAP often treats it is an enlargement of copyright protection.

Moreover, almost undiscussed in a published form, indirect access is used by prominent 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 smaller vendors trying to pull indirect access over on their customers. SAP sets precedents that other vendors on the same client begin to ponder.

Once a customer buys HANA, the other database vendor learns of 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 expanding 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 will 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, 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 showing how HANA connects to Hadoop using their Vora adapter. Hadoop and Spark are their vibrant open-source ecosystem that anyone can try on AWS or Google Cloud (Google offers two flavors, Cloud DataProc and Cloud Dataflow, which are easier to use and self-configuring). However, 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 very widely used Big Data store with a full complement of open source tools. Why can’t the HANA application database (or enterprise data shown in the graph) be copied to Hadoop? The reason is not technical but because SAP’s license for HANA forbids it. Hence, there is a need for a second copy of HANA. 

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

Once again, the SCM (SAP) data goes to HANA and MAPR. However, the sensor and social media data (which are not from SAP, go 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, or CRM (SAP) data is in Oracle, it can go directly to MAPR. However, if any application sits on HANA, it must 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 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 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 that they cannot access it as a regular database. This means that customers need clarity on HANA’s restrictions before they purchase HANA.

Unless the database is tiny, a copy of HANA will be expensive. SAP offers that the client can use SAP Data Services, but what if the customer does want to buy SAP Data Services? SAP has a poor history of 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 is not considered competitive with other ETL tools.

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 buy based upon looney rules with little legal merit in 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 (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? 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, moving to HANA narrows the company’s options, and the costs dramatically increase. This is interesting because SAP has made so much about HANA and 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 does SAP indirect access not apply?

What SAP?

Go to top

Conclusion

HANA is part of an overarching strategy to infiltrate the database layer with all 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 and work in a sales capacity like to repeat statements from SAP marketing literature.

The argument 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 generated by an SAP application. Since users now access 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 complete applications to connect to SAP data. That is, they do not often engage in two-way communication with the data. Instead, they pull data from SAP with far higher frequency (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 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 is that SAP has never had proper reporting tools within its 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, which usually ends up being little used by the actual business.

Under the SAP indirect access logic, every single export into a spreadsheet also cheats 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 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 — that SAP owns your data and that you must 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 changing the rules of systems that have already been purchased.