API Management or Enablement? You Decide

Last week I was at the HTML5 developer conference and then spent the remainder of the week at the API Strategy Conference in San Francisco. All of the keynotes and presentations were great and I think everyone enjoyed a new, cleaned up Kin Lane, whom we hardly recognize now that he is in a suit. One observation resonating among colleagues and attendees is that the API Management space is maturing. In one sense, Kin’s transition in his outward style from hacker to suit is a metaphor for the space as a whole.

This year's conference had a great turnout which shows the space maturing

This year’s conference had a great turnout which shows the space maturing

This was evident at the show as some of the larger companies are entering the space.  Enterprises are waking up to the buzzword of API Management and are looking to see how APIs can help them meet business objectives, in other words, companies are looking inward to see how API management applies value to their existing IT systems as well as their external presence.

Convergence comes when Enterprises look at what they have and try to match their architecture and approaches to the “new world” of API management. I recently participated in a webinar with Forrester’s Randy Heffner that tackled the subject of SOA vs API management head on, entitled “Exposing the Beast: Custom API Management for the Enterprise.”

Randy’s position is that SOA and API management are the same but different. I agree, but I will also add that I think the differences are shrinking, day by day. I am seeing trends in both directions. Cross-pollination is happening and I think that next year’s API strategy conference will have even more traditional Enterprise use cases as well as exciting new innovations for public and open APIs.

For instance, we had Daniel Jacobson’s fireside chat where he claimed that “sub-1 percent of our API calls are public”, this is an astounding number, yet Netflix considers what they do API management. Another example is ancestry.com, which described a scenario where internal developers started using the external API, just because of the improved developer experience (DX). The external API was so easy to use that internal apps started consuming it. Another example was the excellent presentation given by Keith McFarlane, the CTO of LiveOps, a cloud service provider.

In his talk he showed their strategy of wrapping legacy applications with APIs through a migration strategy that first puts a facade in front of the API and then moves the processing into the facade layer. This type of approach is applying the principles of service-orientation and data-sharing to modernize mature (read: legacy) applications that were created to address a need at the current time, but can’t be directly changed without impact current business operations.

What this means is that API management’s original value of a great developer experience is being transported internal to the organization. It’s APIs everywhere and I have been calling this API Enablement, similar to “SOA Enablement” which used to take center-stage in the old “SOA” days. Internal API Management applies what worked about SOA, but to solve internal data silo problems.

Another trend emerging, especially for public APIs is the notion of forward integration for developers. In short, why go pick up a pizza when it can be delivered to you? The concept here is the same. Why go to a developer portal to sign up for an API when you can, in principle, be delivered an SDK in your favorite programming language that wraps the API you want to use? Treating the developer as a customer, this provides the developer the most value and can accelerate the adoption and use of APIs. This was a viewpoint expounded by Mehdi Medjaoui of Webshell.io in his presentation that accompanies a polemic quote, “in a Developer Experience perspective, Developer Portals are a bug, not a feature. But they are here to define a contract between a user/customer and a Provider. It’s a compromise.” This concept goes hand in hand with Pamela Fox’s comment that the best developer experience is no sign-up and no key. It remains to be seen how this concept will play at Enterprises for internal APIs. Faster on-boarding is valuable, but needs to interplay properly with existing entitlements and access control policies.

Overall, the space is growing up fast and I expect to see more Enterprise usage models emerge as we head into 2014, especially around the convergence of SOA and API management into a cohesive solution set for internal, partner or public developers deployed anywhere – on-premise, hybrid, private cloud or in public cloud environments.

API Management Enables Internal APIs

Expressway helps Enterprises power internal and hybrid APIs

 

 

Blake Dournaee

About Blake Dournaee

Passionate, energetic product manager that lives at the intersection of business, innovation and technology. I currently work at Intel in the Datacenter Software Division working on products and technologies relating to mobile, APIs, cloud services and big data.

One Response to API Management or Enablement? You Decide

  1. “Treating the developer as a customer, this provides the developer the most value and can accelerate the adoption and use of APIs. ”

    Great point. Most of us want to find ways to work smarter, no harder. Give the developer the tools they need to do the job and make it easier for them to use those tools.