- SAP API Management is resold Apigee and is promoted to improve integration.
- How valid are SAP’s claims around SAP API Management?
SAP offers the following video on the SAP API Management product. We have placed our observations about the video below the video.
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 very poor 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 for us.
Sharing Mobile Data, IoT and Production Data with SAP API Management?
SAP really only has control over one of these three areas. They have nearly no IoT business, 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?
Analytics can be run 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 difficult to integrate 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 by 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.
There are several problems with this quote. Let us list them.
- 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 prior to S/4HANA implementations. It is unlikely that microservices area true emphasis area for SAP or their customers.
- 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.
- 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.
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 technology foundations. The fact that SAP is reselling Apigee (and combining it with SAP Cloud) really only means that SAP is offering customers the opportunity to be upcharged for a product it has nothing to do with. 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 are developed by Apigee 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 designed 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.
Now, 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 have no disagreement 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 that is entirely controlled by SAP.
And 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 topic of the cloud.
- 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 that want to use Apigee or a similar tool along with 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.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
AWS and Google Cloud Book
Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.
Who is the Most Accurate Source on SAP?
Want to find out? See... A Study into The Accuracy of SAP