You meet them everywhere: At “hackathlon” events, at conferences, in developer forums, at StarBucks, even in the supermarket in front of the cereals and before you can even address them with “Son, why don’t you come over to our side of the platform?” they pull out their light saber, wave the shining and humming blade fiercly in front of your nose and shoot the probing question at you: “Father, what’s your API???”.
So, “what’s your API??”
If we — SAP — want to attract a larger developer community to our technology, then clearly we need to address the needs of this generation of mobile application developers. It’s many of them. And they are active in a highly attractive and massively growing space: mobile apps.
And I believe there are 3 aspects of this that we need to tackle:
- We need to enable our own platform, i.e. SAP NetWeaver Cloud (aka HANA Cloud Platform), at the relevant level with APIs itself. A simple example is management of the platform itself (e.g. deploy, start, stop), but also services like monitoring, configuration etc. are obvious examples.
- We need to make it easy for applications and services built by our partners and customers on top of our NetWeaver Cloud platform, to API-enable their offering. Our customers own highly relevant business content and services and can expose these offerings easily via our NetWeaver Cloud platform to e.g. mobile consumption. This is where the highly valuable business content for a developer community enters the scene.
- We should provide the means to manage those APIs on top of our platform, make it easy to document, find, consume, monitor or meter those APIs. This should come as a service of the platform itself.
This morning, I had my monthly takt-end “Product Review meeting, a day-long meeting where my management team and myself take a look at the aggregated sprint results of our various products in development. We do Scrum in a very systematic way in my organization with around 2000 developers spread around the world. The Product Review takes a full day and constitutes the only “status update” about products and programs that I ask my organization to come up with. And that’s enough, by the way.
Today, we took a look at the current status of Gateway-As-A-Service, which is the SAP NetWeaver Cloud-based incarnation of our SAP NetWeaver Gateway product, a gateway that exposes business functionality implemented in our SAP Business Suite and accessible via Remote Function Calls (RFC), Business APIs (BAPIs), Dynpro screens (via “screen scraping”) and various other programming frameworks, in a standard-compliant manner based on REST and OData protocols (serialized as JSON if needed). So you can easily consume any of the business functionality in e.g. your mobile app in a simple, coherent and standard-compliant way. I am totally excited about the fact that soon our customers and partners will be able to expose any business functionality in the SAP Business Suite to the Internet and mobile applications without even installing an SAP NetWeaver Gateway in their corporate infrastructure, but can do so by simply connecting securely via our Cloud platform where we handle all the infrastructure provisioning. That’s a major step towards getting to those APIs we talked about above. Not the full story about APIs yet, but I am confident we’re getting closer every day…
I am very confident — I am convinced — that we are able to handle all the technical challenges at hand. The bigger challenges we will have to address are the following:
- Bridge — or smooth out — the inherent friction between expectations of extremely straightforward and simple access to business functionality on the consumption side, i.e. for example in the mobile apps space, compared to the variability and complexity of underlying business processes supported in the backend business processes. This will be harder the more “generic” the APIs exposed will be — the intrinsic problem of customizable standard software that can potentially do every variant of a certain process –, and it may be simpler the more specific the use case will be — e.g. if one of our platform customers exposes a specific service to the Internet, it can be completely “hardened out”, resulting in much easier APIs. So perhaps we should rather focus on making it easy to “harden” out specific versions of APIs than trying to expose everything “generically”.
- Solve the business model underlying the API consumption model: It’s great to expose APIs technically, but for sure there need viability and monetization considerations to be taken into account — not just for SAP as a platform provider, but in particular for our customers and partners willing to expose APIs for their services on top of the platform.
So all of this comes with considerable challenges, but the opportunities opened up by such an approach of API level access to the platform and SAP customers’ business use cases are enormous.
“Success is where preparation and opportunity meet.” [Bobby Unser]
Any thoughts out there on this?