How Useful is SAP API Management?

Last Updated on May 18, 2021 by

Executive Summary

  • SAP API Management is resold Apigee and is promoted to improve integration.
  • How valid are SAP’s claims around SAP API Management?

Video Introduction: How Useful is SAP API Management?

Text Introduction (Skip if You Watched the Video)

SAP explains their SAP API Management product that has many holes in it and a problematic future. SAP states that their API management is part of the cloud and that their customers can use API management of IoT, mobile data, and production data. When in reality, these things are not how SAP customers use API Management. SAP makes one false claim about API management after another that will affect people who do not understand how SAP integration really works. You will learn about the major issues with SAP’s explanation of API Management.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Lack of Financial Bias Notice: We have not financial ties to SAP or any other entity mentioned in this article.

  • This is published by a research entity.
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. 

SAP API Management as Part of SAP Cloud?

We have already written about how SAP Cloud is primarily a mechanism for upcharging other cloud providers in the article How to Understand SAP’s Upcharge as a Service. So right off the bat, an item that is part of SAP Cloud is a problematic item to use. Secondly, beyond the inferior financial terms of SAP Cloud, SAP Cloud is a highly inefficient PaaS to use. Therefore the connection between SAP API Management and SAP Cloud is a bit of a deal breaker.

Sharing Mobile Data, IoT, and Production Data with SAP API Management?

SAP only has control over one of these three areas. They have nearly no IoT business, and they are a nonentity in mobile. Therefore this proposed ability to share SAP data among these three areas is not persuasive. The whole “sharing real-time data” statement is very much not educational. Any interface can be scheduled to run in batch or in real time.

Real Time Analytics?

One can run analytics real time, which is called a refresh….but what does this have to do with SAP API Management?

Manage Your Entire Ecosystem of Customers and Suppliers?

SAP has the most difficulty in integrating products in enterprise software. As for collaboration, SAP’s SNC product is no longer functional. Ariba is in decline and has never extended much beyond indirect procurement. In fact, placing one’s data into SAP is one of the best ways to reduce one’s interaction with outside entities. Therefore will all of these areas be magically improved using an API management tool like Apigee or SAP API Management? This seems like quite a stretch.

SAP and Microservices with SAP API Management

This quote is from the Apigee website.

“Many existing and legacy services are not built for modern scale. Consequently, enterprises are adapting legacy services for modern use by breaking up monolithic applications into microservices. In most cases, however, there are already many applications taking advantage of services from the monoliths. The transition to microservices must be done in a way that makes it seamless—invisible to those other applications and developers using the monolith services.

Design and build APIs that developers love. Easily create API proxies and visually configure or code API policies as steps in the API flow. Customize API behavior using JavaScript, Python, or Node.js. Transform from or to any protocol including SOAP, REST, XML binary, and custom protocols.”

There are several problems with this quote.

Let us list them.

Problem #1: SAP is Not About Microservices

Companies are breaking monolithic applications into microservice….but not SAP customers. SAP is firmly a series of monolithic applications, and there is no movement afoot to break them into microservices. What SAP is doing is co-opting the terms around microservices without actually becoming microservice in their design. This is the same issue with using the term containers with SAP. It is not a thing that is presently done with SAP. Secondly, SAP projects have all manner of higher priority items they need to invest in, such as evaluating code before S/4HANA implementations. It is unlikely that microservices are the true emphasis area for SAP or their customers.

Problem #2: SAP Does Not Use Python or Node.js

SAP does not use Python or Node.js. They have documentation around SOAP, REST, and XML, but they are not a “thing” on SAP projects. SAP uses a language called ABAP that has nothing to do with anything mentioned in this quote, along with some Java. And ABAP is distinctly not appropriate for and web development.

Problem #3: SAP Is Not About Programming for Integration

SAP is about creating interfaces with ABAP, sometimes to IDOCS, which are hierarchical files that require extensive transformation. SAP has not changed its integration much since the 1990s, in a way that has meant much for projects (new products have been introduced, but none of them have been competitive with custom integration using programming rather than interfaces, which is a topic we covered in the article How Non Programming Integration Hurts SAP Projects.

Conclusion

We did not evaluate Apigee for this analysis. Apigee may be a great product. However, it does not fit with how SAP operates and its technical foundations. SAP is reselling Apigee (and combining it with SAP Cloud) only means that SAP is offering customers the opportunity to be upcharged for a product; it has nothing to do with it. It never makes sense to purchase a product through SAP because SAP will exaggerate the price and also the claims made by the actual software vendor.

By connecting Apigee/SAP API Management to the SAP Cloud, they drastically reduced the value of Apigee. Not only will SAP demand an upcharge for Apigee, but they will upcharge customers on any usage of APIs that Apigee develops as they will consume cloud services.

The fundamental problem is that SAP does not work anything like the environment that Apigee was designed for. Apigee is intended to manage services run from cloud service providers like AWS and GCP using modern development approaches under the construct of openness.

This is the exact opposite of how SAP environments work.

We should mention that we/Brightwork is very much a supporter of the model proposed by Apigee. And we wrote two books about how to bring cloud services to SAP and Oracle environments and address the topics of microservices and containers and new development approaches taking place in the cloud in great detail. So we agree with the model presented by Apigee. However, this cannot be effectively performed within SAP’s construct. SAP had a comparative advantage in ERP systems, and it is attempting to use the account control built up from its ERP heritage to extend and insert itself into the cloud. Customers should be careful not to let SAP do this because, so far, SAP has added nothing to the cloud except cloud confusion. The leaders in the cloud are far away from SAP in technology and approach. In fact, SAP should be considered an anti-cloud company. And the more customers allow SAP to insert themselves into their cloud, the more the cloud will turn into a negative ROI item entirely controlled by SAP.

All of this is why we are predicting so much cloud expenditure will be wasted through SAP customers taking advice from SAP and their consulting partners on the cloud topic.

  • SAP is a non-starter as a cloud provider or cloud thinker. Most of what SAP states about the cloud is not correct or helpful.
  • Customers who want to use Apigee or a similar tool and innovative cloud service providers for new development should absolutely do this and then connect this SAP independent development back to SAP. However, they should not touch SAP API Management with a ten-foot pole.