11436 SSO

Partner or Open API strategy: Where should you start?

Brian Mulloy
Jan 06, 2011

Embarking on an API project--let alone an enterprise-wide API strategy--can be a scary proposition. It's easy to imagine a big-budget API project costing more than expected, taking longer than planned and ultimately not delivering the anticipated value.

We've observed that many successful API initiatives are done in stages. With each stage more risk and larger investment can be made by building on previous projects.

Stage 1: Internal APIs

Typically the first stage is to create an API for an internal development team to use. Often times at this stage, the demand for an API is driven by the need for mobile applications. The API doesn't have to be perfect, but it has to be good enough to meet the concrete needs of the mobile application. Tackling the internal, mobile project as a first step allows the API team to learn big lessons while keeping the project scope small so that the API starts to add value immediately while setting the ground work for later stage developments.

Stage 2: Partner APIs

The second stage is to collaborate with partners. At the beginning of this phase we see companies work with one or two strategic partners, who will create applications, add-ons or integrations with the API. At this stage the API will be hardened and because the API will be used across organizational boundaries, the API team will learn a new set of lessons including support, documentation, authentication schemes and so on. One key benefit is that the business development team will start to see movement with their backlog of projects into IT. After the API team gets comfortable with a couple strategic partners it is a natural next step to create resource portals and automated systems for provisioning partner keys so that more and more partners can take advantage of the API.

Stage 3: Open Innovation

The final phase is open innovation. After the API team has learned from internal and partner projects there will be a vast amount of institutional wisdom and courage for opening the API to the world of innovative developers, who can take the API in creative, valuable directions for the business.

Exceptions to the rule
Netflix has followed the opposite direction and has found huge success. They started with the open API strategy (as a result of a contest) and found over time that by far most of their traffic came from a few partners who were building streaming services for specific connected devices.  

The month the new interface went out for Xbox, streaming went up very noticeably. While Netflix still supports the public API, they put more focus behind adding and supporting larger partners over 'the long tail' of developer apps, until they had over 200 mobile partners and 25% of prime time internet traffic. Later, internal developers re-engineered their private streaming API.. by using the public API.  

So while long tail innovation is good for buzz... the enterprises that focus on collaboration with partners and customers will win. Even at NPR, the API project was successful because it powered the internal website and partner collaboration.

But what about smaller companies? Many smaller companies or startups might not have large partners that can give them huge distribution. In this case, an open API can be a way to get some uptake of an API. More on that next.

Scaling Microservices