Executive Summary

  • SAP proposes greatly enhanced integration with REST/JSON APIs.
  • We question the consistency of open APIs and with SAP’s other policy of indirect access.


SAP has been telling customers that they are bringing out a large number of REST/JSON APIs. In this article, we will review the likelihood of these APIs becoming prevalent.

The Question

“In recent discussions with SAP they have talked about web services becoming more standard and even mentioned 3000 REST/JSON APIs that are available on the platform (not sure which version?) and that is certainly a technology that my team has been ready for and would like to leverage.

That said, I’m not seeing signs of the many APIs that were reported.

Have you seen any research on SAPs ability to deliver this technology? Is it still in the works? Is there any customer adoption?”

The Analysis

This plan has not been brought to my attention. But there are several reasons to be skeptical.

SAP’s History of Restricting Integration

SAP has always made it difficult to connect to SAP. This is a premeditated strategy designed to direct companies to SAP products. SAP has made numerous statements about making integration easier over the years, but it has tended to stay the same. This is one of the reasons that companies that use SAP have such a high IT overhead. Not only is integrating to SAP difficult but simply extracting data from SAP is more difficult than any other ERP system, because SAP does not allow customers to direct access tables, as do all other ERP vendors.

SAP uses the logic that application integration is so problematic that companies should not connect to non-SAP applications to SAP applications. This allows SAP to argue that using all SAP applications makes an overall implementation work better.

This allows SAP to not compete on the actual application, but to compete as part of an ecosystem.

The Outcome for SAP Customers

The paragraph above has been the long-term strategy of SAP, and most SAP customers believe it, using non-SAP systems only when they find a huge hole in SAP’s offering. This has to lead to deleterious effects for SAP customers as they have loaded up on weak applications ranging from the SAP BW to SAP APO. These applications continually consume large amounts of IT resources and deliver low levels of business value. However this point is not admitted to by IT departments, as IT departments will almost always have “SAP’s back” even when it works against the interests of the companies that employ them.

The Reality of SAP Integration

The only applications that are naturally integrated, or sit on the same database, is SAP’s ERP system. All other SAP applications need to be connected to the ERP system and other SAP systems with adapters. SAP gives the impression that all their SAP applications are naturally integrated, but the customer soon learns that this is not true. The truth is that SAP is not very good at developing adapters. For example, SAP’s integration product called PI is drastically inferior to other integration applications such as those put out by Informatica (as just one example).

In addition to integration limitations with SAP developed applications, SAP has proven to be quite slow in developing adapters to its acquired applications (such as SuccessFactors or Ariba). It is quite common for applications that were acquired over five years ago to still have integration problems.

The Consistency of Open APIs + Indirect Access?

If SAP is opening up technically, why are they closing down access from the legal side?

Every one of those 3000 APIs is a potential indirect access violation.

According to SAP, SAP account executives are “not trained on indirect access,” so they can introduce the APIs one month, and then an “indirect access expert” can show up a year down the line and say “these connections are all indirect access violations, and you owe us $XXX.” There is no what to know if that would actually happen. SAP applies indirect access selectively.

None of my customers are using these APIs, and SAP is always introducing new things, so if they are new, we don’t know if they will take. This is the official site/pages for the APIs

SAP to Non-SAP Integration

SAP and virtually anyone that makes money from SAP has an interesting perspective on the wisdom of using non-SAP systems along with SAP. This is the official story on SAP integration, which tends to differ greatly from the reality of SAP integration. You will learn about our analysis of this narrative.

SAP’s Story and Position on Integrating Non-SAP Systems to SAP

I believe I can represent SAP’s position on this topic accurately. Anyone who disagrees who works for SAP is free to correct my interpretation, but SAP has told me this on some occasions.

  • SAP’s Amazing Best Practices: SAP maintains a catalog of Best Practices that it then incorporates into its software. All of SAP’s software is based upon Best Practices and because SAP is so widely deployed it contains all Best Practices. I have an article that analyzes the best practices claims at this article. That is the first part of the argument.
  • Integration to Non-SAP Systems Must be Avoided: According to SAP, or apparently, virtually anyone who makes money on SAP, integration is so difficult that you should not integrate any non-SAP system to SAP. SAP will concede that some best of breed applications may be slightly better but any business benefit received from using a non-SAP system is immaterial because you will any business benefit will be overcome by such substantial integration costs. In cases where SAP does not have a solution, it makes more sense to wait until SAP brings out one. As stated, it is simply too risky to connect a non-SAP system to SAP.
  • Connecting Non-SAP Applications to SAP Comes with Legal Liabilities Due to Indirect Access: Furthermore, (and this is a recent addition) if you don’t buy all SAP applications, you face indirect access liabilities. Therefore you should be careful not to try to purchase non-SAP applications because it is so risky.

The Reality of Integration Versus the SAP Presentation

This is sort of the problem in enterprise software where it’s all about quota attainment, you can’t get an opinion or advice without getting a biased answer. But the problem with the viewpoints of SAP, SAP consulting companies, and independent SAP consultants is that there is no evidence that application integration is a worse trade-off than customization. Secondly, all of those that draw money from SAP overstate the degree of integration among SAP’s applications. In SAP APO, the integration harness called CIF has very high overhead, integration issues to not simply go away, as is implied in the SAP sales process.

Problems with SAP’s Integration Between Its Own Applications

I constantly receive complaints about the poor integration between SAP’s new acquired products like SuccessFactors, Concur, etc.. Outside of ERP, which is a multi-module system that is completely part of one database, all of SAP’s other applications required integration harnesses. Anyone can develop an integration harness, most vendors have some type of integration to ECC already.

Cost Estimation for Various Solution Architectures

My experience and time spent quantifying the costs of software as well as working on implementations are that the number one feature to look for in software is its actual inherent capabilities and how well it meets business requirements. For those that would tell me how horrible application integration is, unfortunately, I have done it myself. I have created integration harnesses from scratch as part of integration teams.

And I did not even get to use really good tools like Informatica. And secondly what you get out of SAP regarding integration between its applications is not much different than what other vendors offer regarding connecting to SAP.


There are articles going back to 2013 on SAP APIs, and if they are not “a thing” by this time, they probably won’t be.

So it sounds fishy.  If the response requests for real information is that “it is coming” then its probably fake. There has been a tremendous amount of lying and false information about what is really going on behind the scenes with respect to SAP integration. This observation has come from the detailed study that frankly virtually none of the SAP entities I presented above have done themselves. Secondly, it comes from a point with no financial bias. SAP and SAP surrogates like Deloitte, IBM, etc.. cannot make that claim. SAP and their surrogates make their claims about integration not because they are true, but because it makes them the most money to do so. 

To find out about SAP’s API management, see the article How Useful is SAP API Management?

The Problem: A Lack of Fact-Checking of SAP

SAP customers are constantly being tricked by new concepts introduced by SAP. There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

Being Part of the Solution: What to Do About New SAP Products Like SAP API

We can provide feedback from multiple SAP accounts that provide realistic information around SAP products — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the messenger to the bottom right of the page.

Financial Disclosure

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 SAP Integration Content

References, and it looks pretty thin.

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

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