APIs are the glue that connect apps. It’s as true for consumer apps as it is for the enterprise. API management platforms have come into vogue as apps proliferate across the enterprise.
As APIs rise in importance, so has the need for better practices in their creation, development and management. All the major API management services have built strategies that they use as guiding principles when working with customers.
Mashery CEO Oren Michels provided me with an overview of API management that I think also applies to other service providers such as Apigee, Layer 7, Mashape and SOA Software.
These five rules are by no means the final say on API management, but they do provide context for the overall market:
1. Design
Make the APIs accessible to different classes of developers and partners. Develop security policies, usage policies, selective access to data and services. Both Layer 7 and SOA Software cite the need to serve the different constituencies of the enterprise.
Layer 7 Co-Founder and Chief Strategy Officer Dimitri Sirota:
It needs to address each constituency or user group engaged in building and running an API. These include API Architects / Developers, Security Architects, IT Operations and Business Analysts (API marketers). The Layer 7 platform has a product component that addresses each of these stakeholders (API Gateway, API Identity Broker, API Service Manager, API Developer Portal).
A platform by definition needs to be extensible. There needs to be a way to build on top of it. This requires both product APIs and SDK (developer toolkit). Layer 7 supplies both.
Michels adds that it is less about the IT person than the partnerships between IT and the business groups:
Enterprise API Management must include the entire Enterprise, not just the techies in IT. The SOA solution, and the other gateways as well, is focused on the IT person and not the business owner of the API program. This is reflected in the UI that they present in their free version as well as their language that includes things like “policies”; too much of the business rules are codified in complex policies that require a technical expert to really use.
The latter point is particularly important. We’ve been selling API management into the enterprise for five years, and we have yet to see a situation where the tech people are not partnered with business people who have a vested interest in – and will need to manage a big part of – the API management platform.
2. Documentation
To make APIs accessible, offer documentation and communication tools to make it easy to create and manage the applications built on the API itself. Twitter did this very well as a young company but has faltered in its developer communications.
Communication, communication, communication! Twitter started fumbling here in March 2010….and continued to do so with each release. What Twitter is doing is speaking to their developer ecosystem, not communicating with. We are in the age of social media, we need to have conversations not just an outward broadcast of information.
Include developers in the API roadmap. If your going to do an API, have a process for bringing the heavy consumers into the product development process. You don’t have to do everything they say, but make the process inclusive. Otherwise they will revolt. Twitter used to be good about this until Dick took over.
You can’t reap the benefits of an API ecosystem, and not return value to the community.
3. Analytics
Michels said to think about the collection and processing of all the statistics associated with the use of the API, with an eye toward supporting and encouraging effective usage and discouraging/limiting usage that is counter to your business or technology goals.
Apigee has focused significant efforts on its data analytics practice as illustrated in its most recent focus on building APIs for software-defined networks. Here is what I wrote earlier this Fall about the Apigee strategy:
Apigee’s API platform for multi-vendor SDN is stand-alone software that can integrate network management systems with SDN controllers from multiple vendors through real-time API transformations. This software includes network analytics, enabling dynamic policies on the controller itself, as well as network-based programs that can use trends to trigger a change in network behavior. Apigee’s software reads network traffic into a domain model and publishes network traffic analytics as an API.
Sam Ramji, vice president of strategy at Apigee, maintains that analytics will help determine how the infrastructure adapts to different data flows. It’s a view that reflects how software is replacing hardware and the role that data plays in the way apps are calibrated.
Mashape takes a different view, seeing itself as a Google of APIs, offering analytics as a commodity service. CEO Augusto Marietti:
For us the analytics, and all the management things are more like a commodity that we give it for free, just to have more and more distribution and more and more consumption. It’s like Google, that gives you Google Analytics for free, because it helps AdWords as side effect. We’re like an object broker for the cloud computing era. We unify the jungle that the API world is. API consumers have one single API key, consumer console and credit card to consume them all, in the same way.
4. Universal Access
Provide seamless and simple support of the various architectures used by the enterprise, whether public cloud, private cloud, on-premise, or a hybrid of several of these.
5. Uptime
High uptime, easy scalability, and redundancy that handles traffic spikes, works around temporary failures in the enterprise backend, and fails gracefully in the event of a backend outage. SOA Software’s Ian Goldsmith said this for a post I wrote this week about the company’s new enterprise API management platform:
SOA fits the needs of enterprise architects and developers – people who have spent years building extensive infrastructures that can encompass hundreds of software stacks. How to access the data from these stacks is a challenge. Many were architected before APIs emerged as common ways to integrate applications. SOA, as expressed in the name itself, comes out of that age when the principles of “service-oriented architectures” were viewed as the most modern way to integrate multiple on-premise applications into a web environment.
What do you think? What are some other principles to follow when managing APIs?
(Feature image courtesy of XPlane – under Creative Commons.)