It’s an exciting week in API Management with both Intel’s #IDF13 and Business of APIs conference. Most notably was John Musser’s presentation, specifically API Secret #5, which is “Internal Use may be the biggest API use case”
I couldn’t agree more. This point had to be articulated, and John hit it like superman.
If you are pursuing an on-premise API management program this appears to be the #1 requirement. It seems that the core requirement hasn’t changed as we could use a bad word here (OK, I will spell it – “S”, “O”, “A”, “G”, “o”, “v”, “e”, “r”… well you get the picture), but I wanted to talk a little bit about how you can be an Enterprise API Management Hero.
Here is what an Enterprise focused architect, CIO or cloud service provider (CSP) architect is looking for in their API management approach. This list expands Musser’s definition of internal API to partners where we make a distinction from a completely public API where any interested developer can sign-up
Enterprise API Management Hero Checklist
- Expose your data –Low or near-zero cost of surfacing of legacy environments as APIs. Any protocol, data format, or middle-ware system surfaced to a REST/JSON/JSONP/OAuth enabled interface suitable for access by internal apps or HTML5 mobile apps
- Preserve investments & processes – Out of the box connectivity and integration to identity management investments, and more importantly security processes.
- Share easily – API Sharing portal which is completely customizable from a look and feel standpoint and works across multiple data-centers. This usually means there is a component architecture to the portal with a web portal communicating to one or more engines that expose a well-defined API.
- Partner Management – An API sharing data model that supports multiple API providers as multiple tenants with restricted views into their developers and teams.
- Resource Protection – Supports API subscriptions and rate plans to control partners and internal users from overtaking internal resources
- API Docs –Static and Dynamic documentation to support old (word doc/html/xml/soap) and new (rest/json) ways of API sharing
- Performance – Scalable on commodity servers in private cloud environments, public clouds or traditional server scaling.
Did I miss anything? If so, shoot me a comment.