Main content

Evaluating SAP's Apigee API partnership

Jon Reed Profile picture for user jreed October 10, 2014
SAP's Apigee partnership has flown under the radar, but it deserves a closer look. Will SAP be able to get developers on board with its API strategy?

Beyond the noise festival of SAP's Concur acquisition, a quieter alliance is afoot. Since SAP first announced its partnership with Apigee, the SAP developers I know have been left pleased, surprised, or scratching their heads - in some cases, all three.

Most SAP developers don't have a clear sense of SAP's API strategy to begin with. Now an alliance with a leading API platform raises more questions. Does the Apigee partnership mean SAP is upping the ante with exposing its own APIs? And how would Apigee work with SAP's existing assets, such as the HANA Cloud Platform?

At the Apigee "I love APIs" show, I had a chance to meet up with a couple of key API players at SAP. During an additional conversation with Joav Bally, Chief Product Manager for SAP NetWeaver Gateway and SAP API management, I dug into the partnership further.

Why Apigee?

Given SAP is not known as an API champion, why did SAP enter this partnership? Joav:

SAP's number one mission is to make every business a best-run business. With the growth of the app and API economy, we need to make sure our customers can transition along with the market - if we are to keep up with our mission. We decided to go with Apigee as a partner because Apigee provides the API management capabilities our current solutions lack. Also, Apigee is in itself is an API, so we were able to pick and choose the parts we really needed and to integrate with what we had pretty seamlessly.

Caveat: before we go further, I should note that SAP's API team takes issue with my view that SAP has not historically been committed to APIs. In SAP's view, the Apigee partnership is the logical next step in an ongoing process to expose SAP's back end as easily-consumable services, something that has been underway for some years.

SAP points out that Gateway is now in use at more than 11,000 SAP customers, providing a fertile ground for adding API management functionality to the mix. SAP also notes the Odata/REST efforts underway across products, with the objective of being able to connect any device to an SAP system. The SAP Mobile Platform, Lumira, and Fiori are three key SAP solutions that make use of Odata services - making it the right time to add API management to the mix.

sap;s bally
Joav Bally of SAP

But Joav did acknowledge SAP ran into limitations with what Gateway could do as an API platform, making the Apigee partnership the right way forward. Customers were asking for more API capabilities and analytics than Gateway could provide. SAP's API solutions will have features like security and "throttling" functionality that will address the risk of ERP back ends going down as services are exposed.

Joav says that SAP is going through the same digital transition as its customers:

It's not just about helping customers to transition, it's about how SAP is going to pull off this digital transformation. Our plan is to release our own APIs on our own platforms, and attract the developer community to build great applications with those APIs. That's why we decided to partner with Apigee.

The SAP-Apigee partnership - key takeaways

1. SAP API Management 1.0, which is an on-premise solution, is now generally available. Currently, it is a rebadging of Apigee Edge. However, an enhanced feature set is in the works.

2. A cloud-based version of SAP API Management is also underway, with a planned fourth quarter beta. SAP is working with customers currently to co-define that solution, which will be based on Apigee's run time but built in the SAP cloud, on the HANA Cloud Platform.

Given that NetWeaver Gateway already provides access to back end SAP data, I asked Joav what SAP API Management will do for developers beyond what Gateway offers. The answer? SAP API Management will call on pre-defined Gateway services, and expose those services in the cloud. Joav:

We have the first set of capabilities defined. SAP Gateway comes with something called a service catalog  SAP API Management will have out-of-the-box integration with that catalog. You will define an APi proxy, browse the catalog, and call up the relevant service. That means any investment that customers have made into Odata with Gateway, or SOAP with SAP Process Orchestration, or even ESR (Enterprise Services Repository) - these assets can be leveraged, and you will be able to create APIs around them.

3. SAP will develop this integration with Gateway services for both cloud and on-premise versions, but the emphasis will be on API management in the cloud:

The cloud version will be better integrated with other development tools. Based on all the analysis we have done, API management capabilities are largely done in the cloud, so we are catering to this market.

SAP will continue the process of exposing services as APIs for on-premise and cloud products. I asked Joav where the cloud solutions specifically fit into this API plan:

Cloud products such as SuccessFactors, Hybris, and Ariba already come with RESTful services, but the process of exposing APIs is ongoing. SAP is right now exploring the best way to expose its assets on premise and in the cloud to developers. But we do know that  SAP API Management will be how developers access this functionality.

4. SAP plans to utilize Apigee's API functionality via the Hana Cloud Platform. Hana Cloud Integration, which sits on top of the HANA Cloud Platform (HCP), will be tied into Apigee's API management functionality. Joav:

The Hana Cloud Platform is an important ingredient to cloud management - this is also an opportunity to add API management functionality to the SuccessFactors, Ariba, and hybris extension sets as they are built on the HANA Cloud Platform.The bottom line is: SAP intends to have a stronger focus on API management for the cloud applications and extensions running on the HANA Cloud Platform.

Quick hit - developer reaction

I polled several seasoned SAP developers for their initial reactions to the SAP-Apigee announcement. SAP Mentor Graham Robinson, an long-time advocate for a more aggressive API approach, reacted thusly:

When it comes to APIs, my issue with SAP is not that there are no management tools, but that there are no APIs. This announcement does nothing to change that. But what it potentially does is bring the IP that Apigee have on building and running APIs and make it more available and accessible to SAP. Perhaps then SAP can make some of the big moves in this area that I am hoping for. Even on a small scale, a bit of governance around the mishmash of Gateway services that are being rolled out under the Fiori banner would be welcome.

Robinson went on to challenge SAP to integrate APIs management into the HANA Cloud Platform:

If I invest in a cloud platform, and if that platform is the go-to solution for my extensions/enhancements that I will build for both my on-premise solutions - Business Suite - and my cloud solutions - Ariba, SuccessFactors, et al - and any other great ideas I come up with, my first thought is that the cloud platform should provide this functionality itself. I guess I am saying I think maybe API management features should be, or will become, table stakes for a cloud platform.

Robinson concluded by noting: "I can certainly see the need for such a tool, and an increasing demand for one that does the job right for customers with complex and, especially, heterogeneous landscapes."

My take

The SAP-Apigee partnership seems to be spurring SAP to expose its APIs more aggressively. As always, the result will come down to execution. SAP's API fortitude now goes under the microscope.

Where SAP's current API strategy may fall short is with the non-SAP developers that are a major recruitment focus for SAP currently - enough so to feature d-code events not only in Las Vegas and Berlin, but to expand developer events to Silicon Valley and other locations. Non-SAP developers will be looking for simple means of API consumption from SAP that do not require NetWeaver access or licensing.

As of this writing, I don't have a clear idea on how the SAP-Apigee partnership makes life easier for those developers who are not well-versed in the ways of SAP. Hopefully, SAP will have more to say on this point at upcoming events. If SAP were to double down on Cloud Foundry, as Dick Hirsch has urged, that would provide a compelling answer to this question.

SAP's plan to bolster API access to the Hana Cloud Platform  is one of the most intriguing aspects of the Apigee partnership. SAP's depth of commitment to HCP remains somewhat of an open question in my eyes, looming in the shadow of the hosted Hana Enterprise Cloud. But if you talk with SAP executives involved with HCP, they insist that HCP remains a key part of SAP's cloudy development future.

As per SAP's Thomas Grassl, 35,000 developers have signed up for HANA Cloud Platform access, so that lends credibility towards HCP's platform viability. The emphasis on using HCP to extend SuccessFactors (and soon, Ariba and hybris) is another point SAP executives frequently hit on.

The Apigee "I love APIs" show in San Francisco made it clear that Apigee intends to move into analytics and predictive capabilities, powered by their API infrastructure. SAP will take a different tack, directly connecting the HANA database (and HANA's Predictive Analytics) into their remix of Apigee's solution. This may be where a truly distinct product offering emerges - one that is different than Apigee's but in sync with Apigee's "smart API" direction.

One thing we do know: SAP developers will welcome enhanced API access, particularly if it is cloud-based. d-code/TechEd season will provide a good proving ground, and a barometer of SAP's progress.

Special thanks to SAP Mentors Dick Hirsch, Graham Robinson and Ethan Jewett for their input on SAP's API strategy.

Disclosure: SAP is a diginomica premier partner as of this writing. Apigee paid the bulk of my travel and expenses to attend the "I Love APIs" show in San Francisco, where the initial interview with SAP was conducted.

A grey colored placeholder image