What This Article Covers
- The Question on REST/JSON APIs
- The Consistency of Open APIs + 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.
“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?”
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.
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
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. But this can be researched to find out. If the response requests for real information is that “its coming” then its probably fake. This is yet another example of how SAP account executives tell so many lies to prospects from and from so many dimensions.
https://help.sap.com/saphelp_smp304svr/helpdata/en/7c/0a4f017006101484238a3b00c4d5d0/frameset.htm, and it looks pretty thin.
Enterprise Software Risk Book
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