APIs? API management? – Should We be really bothered?
APIs have been around for over a decade now. Early APIs were message ‘contracts’ exchanged between programs. With the advent of Internet, in the early 2000s, slowly there was an explosion of APIs that were web enabled. SOA then helped further shape the API paradigm.
Today the term API is predominantly synonymous with a service that is RESTful in nature and used extensively in area that concern the modern rich web and mobile. With the mass explosion of APIs, there has been a foray of technology and tools that proposes to deliver API management.
The first question that should probably come to ones mind is, ‘What is so special about APIs that we need new technologies/tools in delivering and managing APIs?’.
To answer this, it is important that we understand what APIs really mean today and what managing them comprise of.
What is an API in the context of this article?
An API is;
1. A piece of code that will allow two software programs (applications) communicate with each other.
2. This communication is based on web protocols (HTTP/HTTPS) and is usually based on REST
3. An API will help connect business processes, services and data to both external and internal consumers (devices, applications etc)
4. Abstracts the consumer (ex. web or mobile developer) from the back-end application
Yes. You have guessed it right. This sound so much like a service (or if you prefer interface) one would develop on any integration platform like SAP Process Orchestration, Oracle Fusion, Webmethods etc. So why am I reinventing the wheel?
Now that we have a fair idea of what an API means let’s look at some examples of where APIs are being used. Interestingly, we in many ways are interacting in a world of APIs. Every time you open Facebook or Google, there is an API at work. When you place an order or search for items on Amazon, there are APIs being invoked. Further on, if you have one of those smart watches or fitness devices (wearables) like the NikeFuel, APIs are core to them.
Note: Have you read about the famous Jeff Bezos’ mandate?
So now that we have established that APIs are actually very much integral to our day-today life, let us look at what API management means.
An API Management platform will have the following key characteristics (not limited to the below);
1. Tools for developing APIs (obviously!)
2. Discovery of APIs i.e. cataloguing, searching etc
3. Version and life cycle management
4. Developer Engagement- Controlled access to developer to discover and consume APIs, collaboration opportunities etc
5. Security – Support of standards such as oAuth, SSL, threat protection, encryption, SAML, IAM etc
6. Orchestration – API mashing, branching etc (Orchestration is a big word but try not to confuse this with heavy process based orchestration)
7. API Analytics
8. Caching and Optimization – ex. caching of frequently requested data, compression of messages etc
9. Monetization – A method for monitoring and recording the consumption and traffic of APIs thus incentivising (or the billing) them.
Q: Do we still need a platform for doing APIs? Cant investments in existing enterprise grade Integration/BPM technologies realize this for us?
It is important that we answer this question right away because only then is it possible for us to understand the value proposition that API management will deliver.
The core requirements/use cases APIs will serve are around mobile, web and the IoT space. This means we are looking at real time service calls that requires low latency to be maintained throughout. APIs usually do not accommodate heavy logic or orchestration and are philosophically KISS (Keep It Simple Stupid!) in nature.
The enterprise service bus, SOA and business process management platforms are sophisticated tools that manage a wide variety of integration and orchestration patterns but what makes API management a bit unique from the traditional A2A and B2B integration, is the aspect of functionalities like Developer Engagement, Caching, Incentivisation and support for standards such as OAuth. Analytics and reporting around APIs is also a key aspect.
More on Analytics & Incentivisation of APIs:
Some examples of what Analytics, reporting and Metrics means in the case of API management;
a. Analysis of traffic – This could be number of transactions, the source of the traffic etc
b. API trends – Availability, top trending API, least used API, error categories, error rates etc
c. Developer statistics – Number of Developers engaged, top developers, APIs by developers etc
Incentivisation is all about how to monetize APIs. There can be different models that organizations might wish to adopt. Some may be a ‘Pay as You go’ model or an unit based where the costs are proportioned according to the consumption of the APIs, another could be a revenue sharing model where the organization pays the developer or say a partner based on the revenue generated by the APIs developed by them, some organizations might even just simply choose to give away APIs for free so as to drive market adoption.
By now, it should have become clear that the Enterprise Integration and the API management technologies both have overlaps but are distinctly unique in the use cases they cater to serve. Thus in an organization that is finding itself stepping into significant mobile adoption, the consumerization of IT and those with predominant B2C interactions along with B2E and B2B, setting up APIs and the required technology to manage it becomes an exciting value proposition.
If your organization answers ‘Yes’ to the majority of the below questions, then you should potentially start evaluating the benefits of an API management solution;
1. Does your organisation have a strategy or vision around the adoption of mobility?
2. Are you looking to extend the collaboration and development of APIs to external parties, vendors or developers?
3. Will you be exposing your organization business data for public consumption?
4. Do you want to analyse trends of data consumption and utilize sentiment analysis of your social channels?
5. Is your business primarily front ended by the web or is the web the core channel your customer engage with you?
6. Does the word ‘User Experience’ keep getting mentioned in your strategic meetings?
In the modern enterprise landscape, thus the core integration and orchestration technologies (ESB, BPM, MFT etc) will continue to hold their place but will now start finding itself possibly accompanied by the new stack i.e. API management, each serving purposes, it is best capable to deliver.
SAP has also realized the technological gaps it has in its product suite. The recent partnership with the industry leader in API management, Apigee, is a sign of SAP desperately trying to bridge gaps and strengthen its overall solution stack.
Note: Refer this blog for insights into the Integration and Orchestration offerings from SAP
So now I come back to the title of this blog and would like to ask the reader, ‘Should we be really bothered about API management?’. Do post your thoughts in the comment section of this blog and hope to have an engaging discussion.
Application Program Interface was once just a piece of code that was often delivered with the product but mostly unused/untouched, primarily because no one knew it exist.
Once an awareness of the use cases is spread a need to manage it surely arise
Two questions
1. Will the traditional owners of integration layer (ESB/PI/PO/OFM etc) be the new masters of the API management?
2. Is it a Rocket Science (specialized requirements with unique skill set to manage it)?
1. Will the traditional owners of integration layer (ESB/PI/PO/OFM etc) be the new masters of the API management?
>>>>>
I would assume a yes and a no 🙂 Yes because for many organizations with established CoEs or an ICC it would not be a significant task to upskill and manage the new technology. But the catch is API management and the governance around this is not strictly tight as would be the case of SOA. APIs look to serve the Systems of Innovation stack which means an agile, fast delivery methodology which could be managed separately.
2. Is it a Rocket Science (specialized requirements with unique skill set to manage it)?
>>>>>
I did mention KISS somewhere in the blog. So drawing inspiration from that I will have to say this is definitely not rocket science and would be an upskilling with a smooth learning curve.
API Management would soon be the need of many industries. Yes the governance around API management is not as robust as SOA, but a certain sector of industries would still go for it.
I may be wrong , but currently SAP API Management is not so popular, but the primary reason around it would be the assumption , it being a rocket science . There is need to b awareness , it can be simplified and easy .
Yes it would be great if the product is made more mature , and plug in / merging with existing SAP modules is popularised .
Hi Shab
In the (olden) days of SOA (or ESOA as SAP prefers to call their own version of it), we had the Services Registry that was/is part of PI. It was UDDI compliant and was supposed to herald us into an age where SAP-based web services was easily discovered and consumed within an SOA landscape. I'm not sure about others' experience, but it was never used at all in any of the integration projects that I was on. I wonder what the adoption rate for it at SAP's customers is like.
As for inter-company integration, my experience has been that most companies still do it the traditional B2B approach which relies heavily on EDI standards and still tightly coupled (and possibly heavily customized) between both partners. There isn't much of the provisioning/consumption model that lies at the core of API design/architecture. And there isn't too much emphasis on provisioning SAP backend services for the external world to consume.
Anyway, this could also be due to the fact that maybe I have not had the privilege to work at exciting, forward-looking organizations. 😉
Fast forward to these days of cloud, mobile and IoT - how would these new API management fit in to organizations that use SAP systems heavily? What type of SAP functionality (ERP, HCM, CRM, etc) are suitable to be exposed for public consumption? How would this fit into the various suite of SAP products that are available like Services Registry, OData, Gateway, etc?
I take my leave with this image I saw on Linkedin recently 🙂 Could the same be said about the X, Y, Z products that we see coming out from SAP these days? 😛
Rgds
Eng Swee
Thanks for the note Eng.
I feel SAP has been trying to tackle this problem for a while. With Gateway they started putting in the basic blocks but yet again it was so SAP (read ABAP) centric solution. I am sure there would have been an onslaught of feedback that then forced SAP to deliver Integration gateway (Java Gateway) on the SMP platform. Now recently they have released a roadmap that will provision Integration Gateway on PO. They have also released a REST adapter on PO. Thus this is how SAP is trying to make sure their platforms are capable of exposing any backend data as OData or plain REST. Better late than never I think!
The apigee seems like a good progress for something new. As you say lot of the new features is comming to SAP PO/Gateway, but they will not get to the vision about getting 1 billion users. It is still too much SAP, and this is probably here APIgee can make it easier to onboard new developers and have the enterprice security required.
Of course. The needs of true API management to be delivered on existing SAP technologies would be a uphill task. Hence it makes sense for SAP to partner with leaders in this space to fulfil gaps.
Hi Shabarish
Hope I didn't come across as being too critical in my previous comment. It's just that I struggle to visualize how all these API-thingy will come together from an SAP perspective.
In my current project, we are integrating with Concur's T&E cloud solution (which SAP so happen to acquire recently). Concur has a decent suite of RESTful APIs that fits the KISS philosophy. It is quite well documented, accessible online and has all the CRUD methods to perform the different action.
However, when I try to imagine APIs from an SAP-backend functionality perspective, I can't picture them being KISS-like. Even though we can REST-enable the backend functionality via Gateway or the REST adapter, the nature of the backend functionality is still complex. As you mentioned above, the solution is still very SAP/ABAP centric. The existing BAPIs/RFCs for the various master data and transactional data are still pretty cumbersome. With all the complex relationship between the different database tables, I can't imagine exposing them via Gateway will automatically give us RESTful CRUD services that are KISS-like.
Will SAP be building new backend functionality (BAPIs, RFCs, etc) that are easily translatable to CRUD services?
What about existing ESR-based service provider proxies? Will these be phased out in favor of Gateway-exposed services?
All in all, I think the following blog by Christian Drumm articulates it better than my messy thoughts here.
Hello SAP, where are my APIs?
Looking forward to knowing what your thoughts are - maybe you are privy so some inside info 🙂
Rgds
Eng Swee
The SAP backend in itself is a System of Record. Any enterprise business system will retain its complexity. In case of SAP, we do observe small steps being made i.e. the transition from traditional RFCs to support for OData based services exposing backend data (HANA does OData very smoothly).
I personally feel that to expect these massive business application to align themselves towards an API strategy might be a big ask in itself. But when we move away from the onpremise notion to cloud deployments, it becomes imperative that the solution supports a wide range of APIs (the case of Concur).
On the scale of an enterprise, a hybrid model of business application spread on-premise and on-demand find massive adoption. So in a solution stack, the integration or the API layer needs to play the role of consuming any backend and then enabling the business data as the required services (APIs).
Also APIs in themselves serve basic data needs. Examples such as retrieve product catalogues, information on customer(s), check availability, create, update, reschedule of appointments etc. So the idea will be enable micro services rather than one big service (fits all size).
My frustration with SAP has always been around disconnected solutions. There are so many products that overlap and it becomes very difficult to justify the use of them. Ex. Gateway, Integration gateway and SAP PO - All are products that can provision APIs (none of them do API management though). Hopefully SAP is looking at consolidating their Integration portfolio.
The key here is that the core integration suite will continue to exist as it serves a multitude of purposes that will not go away anytime soon. The smart thing will be to then look at platforms that will coexist and serve the needs of the modern enterprise and the consumerization of IT.
I think even some of the folks at SAP themselves are confused by their company's offerings. The client I'm at now had a situation when they were evaluating solutions to consume Concur's RESTful API services. It was just before SAP released their REST adapter, so the SAP folks end up proposing the usage of Gateway instead!! *facepalm*
(In the end the client went for Advantco's offering)
Hi Shabrish,
It as nice blog for an Overview about API.
People can get a good picture of API from this Blog.
Thanks for posting. 😎
This is a very good question!
I think that in the end Enterprise Integration and the API management will merge (but not for now).
Concerning Should we be really bothered about API management? the anwser is YES!
Even for companies who already have an SOA and ESB, API governance needs to be more smooth and versatile than SOA's. API management solution can bring all this to more rigid existing systems (and of course bring all needed tools to handle API like developer engagement).