- Information has been coming from many SAP customers on strange indirect access charges.
- There is no basis in law of indirect access and is an example of SAP pushing the boundaries.
- SAP also provides an inconsistent position on indirect access.
- There are great limitations on HANA flexibility and usage.
- We cover a company’s options with HANA and indirect access.
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 their system. The fundamentals of indirect access or IA is 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 protection, 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 important 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 very strict 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.
- SAP’s position is that that the client must use SAP Data Services.
- 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 own 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 the 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 very happy 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.
- Why is the second instance of HANA required?
- If HANA cannot be technically or from a license perspective have data extracted from it, why does a purchase of a second HANA database change that fact?
- What are the cost implications of all of this?
- 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 normal 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 very small, 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 regards, I am in good company. Based upon this history, it is very unlikely that it will be of good enough quality to justify purchasing it. Moreover, SAP should not dictate which integration products SAP customers to purchase, 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 current 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 simply 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?
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 has 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 extra 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 normally 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 good reporting tools within their applications, and it is tough to compete with a spreadsheet. Even with Tableau on the scene, which has very good 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 often 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.
Doing Something About It
SAP relies upon compliant entities like the big consulting companies and compliant media that are in some shape or form on SAP’s payroll to keep other customers from finding out about these types of things. IBM Accenture and others will keep this hidden as long as possible because they want the implementation business. They will tell you how great HANA is but are contractually obligated to need messaging to SAP. While IBM as no fiduciary responsibility to its customers, it does have a partnership responsibility to SAP. It is curious, but in all the projects I have worked with IBM, Accenture, and others, the only interests aside from their own I have ever seen them respect is SAP’s. But never their actual customers.
Since major consulting companies or media outlets can be relied upon to be silent (called being a good or compliant SAP partner), and SAP will spring this on customers at the time of their choosing. But if this has happened to you or your client, please do comment.
That fights against enlarged indirect access rules supported by the largest vendors. If you are a vendor that faces block out due to indirect access, you should consider supporting the newly formed entity. The benefits include supporting efforts in the area, which means more coverage as well as information sharing.
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.
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