- SAP filed a motion to dismiss Teradata’s complaint.
- How accurate are the statements proposed in the motion to dismiss?
Introduction to the SAP vs Teradata Lawsuit
Teradata filed a complaint against SAP in June of 2018 asserting many things that Brightwork Research & Analysis has been saying for several years. (although our research does not agree with all of Teradata’s allegations.)
Naturally, SAP said they did nothing wrong, and filed a motion to have the complaint dismissed. The reporting of the contents of the motion is from The Register. We looked for but were not able to find the actual motion to dismiss. We evaluate SAP’s statements against our own research.
We have any financial or non-financial relationship with either SAP or Teradata.
Now let us get to the quotes from the motion.
SAP Changing the Topic on the Teradata’s Complaint
“It (the complaint) also made antitrust allegations claiming SAP had attempted to edge Teradata out of the market by locking customers into its tech, noting the German giant’s ERP suite S/4HANA can only run on HANA.
However, SAP slammed these claims in a motion to have the case dismissed for once and for all, which was filed with the District Court of Northern California at the end of last month.
It argued the joint venture, known as the Bridge Project, started because Teradata “had a limited customer base” and wanted to appeal to SAP’s users – but SAP painted Teradata’s push as wildly unsuccessful, saying that just one customer signed up.”
This is not related to at least the heart of Teradata’s complaint. When SAP partners with a vendor it is never (from SAP’s perspective) to improve that vendor’s ability to sell into SAP’s customers. SAP uses partnerships to neuter competitors and to copy intellectual property, but normally work against the competing vendor’s interests. As we covered in the article How SAP’s Partnership Agreement Blocks Vendors from Fighting Indirect Access, partnerships with SAP have helped to keep competing vendors from publicly complaining about indirect access.
This is of course not to deny that Teradata wanted to appeal to SAP’s users/customers. They certainly did. That is always the motivation for vendors to engage in partnerships with SAP. However, Teradata had been doing this for decades…..that is before SAP introduced HANA and began deliberately blocking out other database vendors. Teradata’s complaint is that SAP effectively blocked them out of accounts that they shared by using HANA and the restrictions around HANA to do so. We covered this topic in the article The HANA Police.
Therefore, in this argument, SAP is attempting misdirection.
HANA is Innovative?
“SAP had been working on its own database product for years before that deal, it said, and branded “the assertion that HANA is the result of anything but SAP’s technological innovation, investment, and development is factually groundless”.
Teradata was only bringing the lawsuit because it has “fallen behind” the competition, SAP claimed.”
SAP did not “work on its own database product for years before the deal.” SAP had several databases for years, and they also acquired Sybase, but those are not related to this topic. What ended up becoming HANA were two small acquisitions purchased roughly a year before HANA was released. We covered in the article Did Hasso Plattner and His Ph.D. Students Invent HANA? That while SAP falsified a story around Hasso Plattner and his students creating HANA from scratch, the supporting technologies for HANA was purchased with the intent of making them into HANA. SAP’s big addition to the design was to remove aggregates and indexes. Hasso Plattner nor Vishal Sikka, nor Hasso Plattner’s Ph.D. students ever contributed anything that could be called intellectual property to the exercise.
How do we know?
We analyzed what was claimed by Hasso Plattner in his books and in the SAP marketing/sales material where these contentions were made.
Hasso Plattner’s books aren’t so much books as marketing pitches. Riddled with exaggerations and inaccuracies, part of what Hasso Plattner’s books do is create a narrative where Hasso and SAP created some superlative innovation in column-oriented databases. None of Hasso’s claims regarding innovation hold up to scrutiny. All of Hasso’s books (4 in total) have one purpose….not to inform, but to sell HANA.
There is little doubt that Teradata had superior database knowledge and that SAP did seek to learn from Teradata and to use the partnership to do so. Furthermore, SAP has a history of doing exactly that with other software vendors. SAP’s xApp program was really an extensive competitive intelligence gathering operation designed to extract IP from vendors so that it could be placed into SAP’s products. We covered the xApp program in 2010 in the article Its Time for the xApp Program to End.
HANA’s design is highly problematic and cannot meet SAP’s statements about it — except in analytics, where it is only better than older versions of competitive databases and only when using far larger hardware footprints as covered in How Much of HANA’s Performance is Hardware? SAP’s statements about HANA’s superiority are false.
The Mystery of HANA’s Lack of Use Outside of SAP Accounts
HANA is not purchased outside of SAP accounts; it is only purchased by accounts controlled by SAP where the IT customers failed to perform their research into SAP’s claims. If the outlandish claims around HANA are true, why aren’t non-SAP customers using it? No other database fits this profile.
- Oracle sells databases to everyone not just to customers that buy Oracle’s applications and where they have account control.
- SQL Server is found everywhere, not only on accounts where Microsoft sells their ERP system.
Bill McDermott stated that HANA works “100,000 times faster than any competing technology.” If that is true, why do only SAP customers buy it?
Teradata’s IP Puffery
Through the original complaint, Teradata overstates its intellectual property implying that they have some secret sauce no one else has. The designs that are similar to HANA are all over the place. AWS has Redshift which is similar in design to HANA. And both Google Cloud and AWS have Redis, which is also similar to HANA (although in a different dimension). Reading Teradata’s complaint is symptomatic of commercial software companies perpetually overstating how unique their software is. However, the claim is axiomatic, declarations of uniqueness and innovation are known to correlate with commercial software sales positively. Teradata’s complaint also exclaims how employees are made to sign NDAs so that Teradata’s technology secrets are not distributed outside of Teradata, but neglects to mention how much Teradata benefits from those same employees add to Teradata’s IP. Apparently, by inference, all of the Teradata IP was created by executives, and not employees. And where did Teradata originally develop its database from? That is right, from using database concepts that were in the public domain.
As with pharmaceutical companies which commercialize research that performed by universities and is funded by taxpayers through the National Institutes of Health, as soon as a software vendor wants to sell software, the public domain very conveniently recedes into the background, and the narrative of “their IP” is wheeled out front and center.
Big Money Equals More IP Protection?
As readers can tell, we find the IP theft argument made by Teradata to be the least persuasive part of their complaint. Other vendors have far greater claims regarding SAP stealing their IP than does Teradata. But Teradata is a rich software vendor and has the money to bring a case like this. Therefore, their IP concerns are considered relevant, whereas a smaller software vendor’s IP concerns are considered less relevant (perhaps irrelevant?).
Teradata Has Fallen Behind…….SAP’s Marketing Department?
SAP states that Teradata has “fallen behind” SAP. However, in technical circles, SAP is still not a respected database vendor. Teradata, although they are known to charge far too much for what they offer and to overpromise, are technically respected. The only place that Teradata has fallen behind SAP in databases is in marketing.
Teradata Cannot Compete with S/4HANA?
SAP goes on to make an assertion that is so absurd, that SAP must believe the judge will make zero effort to fact check the statement.
“Teradata has not been able to compete effectively with S/4HANA because it only focuses on its flagship analytical database and has failed to offer innovative and relevant compelling products,” the filing stated.
Teradata does not compete with S/4HANA. They compete with HANA.
The reason Teradata has not been able to compete in SAP customers with S/4HANA is that SAP made it a requirement that HANA only copy data to a second instance of HANA. This made Teradata uncompetitive as it would massively increase the cost (HANA is an exorbitant database in its TCO, which we estimated in the Brightwork Study into SAP HANA’s TCO) This is not merely a Teradata issue, SAP is using these rules against all the database competitors and using them against SAP customers. Reports of these abuses come in from different places around the world to us.
Therefore, SAP’s statement about failing to offer innovative and “relevant competing products” rings hollow. This is particularly true since HANA is not an innovative product, but as we covered, in Did SAP Simply Reinvent the Wheel with HANA.
SAP backward engineered other databases combined with its acquisitions of other database components. To hide this backward engineering, and to seem innovative, SAP has renamed items that already had generally accepted names. For instance, what SAP calls “code pushdown” is simply the same old stored procedure as we covered in How Accurate are SAP’s Arguments on Code Pushdown and CDSs.
Teradata Must Develop an ERP System to Compete?
The sentence related to Teradata only focusing on its “flagship analytical database” by SAP contains an important assumption that should be fleshed out by the judge during the case. The assumption made clear by this statement is that Teradata should not offer only analytical/database products to compete with SAP, but needs to develop its own ERP system.
This fits within the construct that SAP finds appealing, which is that the ERP vendor should control the entire account. And it is an inherently anti-competitive assumption. What is most curious, is that SAP does not even appear to realize how this exposes them as monopolistic in their thought processes. That is not supposed to be the assumption of ERP systems. ERP vendors are entitled to offer the customer more products, but selling the ERP system to a customer does not entitle that vendor to all of the IT spend of that company.
SAP Lacks Power in Its Own Customers?
One has to really stand in awe of SAP’s next proposal to the judge. SAP would like the judge to think that SAP lacks influence in……SAP accounts.
“SAP said Teradata’s allegations that it was monopolising the enterprise data analytics and warehousing market also fell flat, arguing it had failed to even identify SAP’s power in that market.
“The [complaint] alleges nothing more than that Teradata now has to compete in its favored marketplace,” SAP said.”
Here SAP’s attorneys try another sleight of hand. Rather than addressing anything true, SAP’s (what must be very highly paid) attorneys prefer to change the subject to see if the judge will notice.
Can judges be hypnotized? If so, SAP has a chance with this argument.
Teradata’s allegation is that SAP is blocking them out of SAP accounts. And that this is anti-competitive. SAP has created false technical proposals including the incredible bizarre restrictions that HANA must be copied only to HANA and not to Teradata. I have discussed these limitations with people with decades of database experience, and none of us can make any sense of the restrictions. They are unprecedented and designed merely to capture market share. Those are real impediments to Teradata, and they are meant to be.
Furthermore, these restrictions are costing SAP customers in a major way. SAP wants customers to upgrade to S/4HANA, which comes with HANA, and as soon as they do, they will find themselves subject to all manner of restrictions that did not exist with the previous database they were using (Oracle, DB2, SQL Server). SAP plans to use these restrictions to push out from ERP making HANA mandatory and “making the customer’s choice for them.”
Teradata need not identify SAP’s “power in the analytics market,” as SAP has enormous and undisputed power in their clients. Anyone who has worked in SAP consulting knows this. Now those clients previously were happy to use Teradata and SAP side by side and did for many years. But SAP, through these restrictions made it difficult for Teradata to continue to do business in SAP accounts. In fact, according to the Teradata complaint, many of their customers they shared with SAP gave them ultimatums that they would have the previous levels of interoperability with SAP, or their customers would leave them. This is quite believable, as SAP greatly reduced the value of Teradata in SAP accounts by making the integration to Teradata so much more expensive.
The entirety of SAP’s restrictive policies is to injure competitors and to absorb more income from customers. SAP is in a particularly weak position here now that all of their claims regarding HANA’s superiority have been pierced as we covered in Articles that Exaggerate HANA’s Benefits and How to Deflect That Your Were Wrong About HANA.
S/4HANA and HANA are the Same Product?
“Regarding antitrust claims, SAP said Teradata “does not plausibly allege that SAP coerces its customers into purchasing HANA”. It added assertions that S/4HANA unlawfully ties HANA to ERP software are misguided, as they aren’t separate products.
Rather, it is one integrated product sold to customers as so, compared to separate ERP and database wares.”
SAP’s attorneys should have checked this with the technical resources at SAP because these two paragraphs are unsupportable and make it plain that the attorneys mean to trick the judge.
First S/4HANA is unlawfully tied to HANA because…
- a) There is no technical reason to restrict S/4HANA to HANA. The evidence is that HANA underperforms the competing database alternatives as we covered in What is the Actual Performance of HANA. and..
- b) Products that are tied together in order block out competitors are illegal under the tying arrangement clause of the US antitrust law. This is the exact clause of our antitrust law used by the DOJ to win a judgment against Microsoft back in the 1990s.
Something else which will be difficult for SAP to explain — how is an application like S/4HANA and a database like HANA a single integrated product? Can SAP name another ERP system that is “integrated as a product with its database?” Here is another question, if S/4HANA and HANA are the same product, why are they priced separately and listed as different products in the SAP price list? A third question. Is HANA now integrated to the BW also? As BW can be deployed on HANA, they must also be a single fused product!
Teradata’s Real Complaint is SAP Would Not Integrate with Teradata’s DB?
“Teradata’s real complaint is that SAP chose to offer this integrated system with HANA, rather than integrating with Teradata’s database; the antitrust laws, however, are designed to prevent injury to competition, rather than injury to competitors,” SAP said.”
This is a very strange wording by SAP. However, the issue that SAP is hoping the judge is confused by is that the restrictions are not technical. Teradata has been integrating to (often Oracle) databases on customers with SAP applications for decades. The issue is not technical; it is how SAP setup the charges and used indirect access to cut off their database from being accessed by Teradata. Indirect access is a violation of the tying arrangement discussed previously and covered in the article SAP’s Indirect Access Violates US Anti Trust Law. Notice Teradata’s use of the specific term tying arrangement in this quote from the complaint.
“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 in coercing customers to adopt HANA.”
The second part of the paragraph from the SAP quotation regarding “designed to prevent injury to competition, rather than injury to competitors seems to be some type of wordplay. This would be like saying laws against murder are designed to protect society in general but are not designed to protect the murder of any one particular person.
Teradata is being blocked because of SAP’s unwarranted tying arrangement between S/4HANA and HANA. Teradata is a competitor, and SAP is not competing with them by offering customers to choose between HANA and Teradata. They are using the SAP ERP system, previous versions which did not have these restrictions, to be restricted.
This is stated in the Teradata complaint.
“Moreover, and on information and belief, SAP has begun significantly restricting Teradata’s ability to access customers’ SAP-derived data. Through this conduct, SAP has deliberately sought to exploit its large, existing ERP customer base to the detriment of Teradata and its customers. Given the extremely high costs of switching ERP providers, SAP’s ERP customers are effectively locked-in to using SAP’s ERP Applications, and SAP is now attempting to lock them into using only HANA in the EDAW market as well.”
This is the exact reason we have argued against ERP systems; they are continually used to take control of the customer’s IT spend through account control, as covered in the article How ERP Systems Were a Trojan Horse.
The strategy by SAP’s attorneys here is called “muddying the water.”
SAP Requires More Explanation as to Inefficiencies?
“For instance, SAP said the US-based Teradata was vague about the “inefficiencies” it claims to have identified in SAP’s systems it offered; failed to precisely identify what trade secrets were stolen; and failed to allege that SAP breached the contracts drawn up for the Bridge Project.
“To the contrary, much of what the [complaint] alleges as purported misconduct (which SAP denies) is expressly permitted by the relevant provisions of the Bridge Project Agreements,” the ERP giant said.”
What can be taken from this motion to dismiss? The arguments related to trade secrets seem correct. SAP most likely did benefit from Teradata’s advice and expertise related to how to improve HANA. SAP would have naturally tried to learn things from Teradata. SAP was very unsophisticated regarding databases, particularly back when they were cobbling together HANA from acquisitions and with ideas gleaned from other databases vendors. But this backward engineering was not restricted to Teradata. And we have yet to see evidence that Teradata offered a substantial portion of IP that eventually became HANA.
Furthermore, HANA is not a competitive product. Therefore, whatever SAP may have taken from Teradata was either not particularly good, or SAP screwed up the implementation of the concept. HANA’s power comes from its association with SAP, not from HANA’s capabilities as a product.
SAP’s arguments against Teradata’s claims regarding anti-competitive behavior go beyond anything reasonable, dance in the area of insulating and make one wonder about the attorneys used by SAP. Any person who would make these arguments to me would so ruin their credibility; I would never listen to them again.
The impression given is that SAP hopes to find a weak judge who would believe such arguments. A motion to dismiss is automatic, but if this is what SAP came up with (assuming there was no miscommunication with the attorneys and SAP) this case appears to be a substantial risk for SAP. Teradata is asking for SAP to change the way they do business essentially. Teradata’s request is entirely consistent with demanding the SAP follow the normal rules of competition. SAP is asking that the US courts allow them to use tricks and deception to push vendors out of “their” customers. SAP claims to own them because they have sold them an ERP system. Teradata is asking for the courts to bar some of SAP’s behaviors as covered in the following quotation in the Teradata complaint.
“Teradata therefore is entitled to an injunction barring SAP’s illegal conduct, monetary damages, and all other legal and equitable relief available under law and which the court may deem proper.”
US courts are not the best place for anticompetitive enforcement. One question might be, why is the FTC not investigating SAP? The exact issues listed by Teradata in their complaint have been reported to us for years. But as the FTC no longer is interested in enforcing antitrust law, this is Teradata’s only option. The US economy is increasingly dominated by larger and larger entities, something which reduces competition and depresses wages.
Other vendors should show an interest in this case because SAP is claiming the vendor selling the ERP system has the right to push the other vendors from the account. If the US courts allow them to do it to Teradata, which is a vendor with large amounts of resources, they can do it to anyone.
Advice on Enjoying the Quiz
To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.
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.
Search Our Other IT Lawsuits Content
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