For the past year, leading analysts have said SOA has become a de-facto standard for all new application architectures. Which makes it hard to believe just 5 years ago, most people didn’t understand the value of SOA or how they can use it. A similar shift is unfolding today in the world of APIs. APIs are already driving significant new economic activity. Salesforce.com for instance, generates half of its $2B+ revenue via APIs. Thousands of mobile apps have been built using Twitter, Google and Facebook APIs. Netflix has over 100,000 DVD titles that it exposes through APIs for integration with over 200 devices, including mobile.
But why API’s and why now?
Technically an API (Application Programming Interface) simply defines an immutable contract between API consumers and providers. It is the implementation of the API that actually packages data and/or business logic. What’s changed in the last couple of years is the number of target devices for deploying applications. The options are multiplying rapidly, be it web, smartphones, tablets, laptops, or even cars. By 2020, there would be no less than 10 billion mobile devices in the world.
Which leads to the expectation of a user experience that now widely varies by the user’s needs, preferred devices, and context. It is becoming increasingly difficult for enterprise IT to serve the needs of such a diverse mix of users. That’s where APIs step in. APIs allow any app development shop out there to create apps that can serve the needs of a specific segment of users. It is a “win-win-win” situation – Users get what they want, app developers monetize the apps they build and enterprise IT gets to serve its diverse end users.
In fact, some of the most popular apps, came out of developer hack-a-thons where developers combined APIs from multiple companies to create a highly innovative app. Without publicly available API’s, this would not have been possible. (See another post in this blog, the API trifecta around the topic of innovation and APIs). APIs therefore, provide a distribution channel for a company’s products and services. Increasingly we are seeing evidence of this in industries across the board but especially in sectors such as media, retail, travel and government. As an IT leader if you decide to provision your APIs externally, you would naturally want to manage them.
So what does that mean in terms of the capabilities you need?
At the highest level, an API management solution needs to include a –
- Developer Portal for developers to discover APIs, understand usage and sign up for access
- API Gateway that secures and mediates the traffic between your APIs and its consumers
- API Lifecycle Management to manage the process of designing, developing, deploying, versioning and retiring APIs
Of course, the above capabilities may be delivered as-a-service or on-premise or some combination.
If you are with me so far, you are probably now asking –
So how’s API management different from SOA Governance?
There’s quite a bit of confusion out there. You are not alone. That’s because there is significant overlap between the capabilities that are needed to manage APIs and govern an SOA. The key difference lies in the objectives of these two initiatives. API management is concerned with managing external APIs where consumers are unknown. SOA Governance, on the other hand, is about managing services with known consumers. Note that even for SOA the consumers don’t have to be internal. They could be your business partners who are external but known in advance. (And to be sure, external = outside your firewall.) This distinction leads to design and deployment choices that at times masquerade as differences, adding to the confusion. For instance, REST based APIs are much more popular than SOAP ones, but that’s only because REST services are a lot easier to consume.
Is this helpful in furthering your understanding of API management? Let me know what else you would like to know about API Management.
P.S. What’s common between cowboys, railroads and API management? Stumped? See what my colleague wrote a few months ago on this subject.