Getting Enterprises Using Your APIs: Understanding the Challenges and Workarounds

Guest Author, September 12th, 2012

This guest post comes from Jaime Ryan, Partner Architect at Layer 7 Technologies, an API Management company. Jaime works with technology partners to define strategy and architectures for successful customer deployments. You can follow him on his blog.

Every API needs developers, and the set of core attributes used for attracting that audience of developers has been widely discussed. The quality of the data or application being exposed and the elegance of the API itself are prime factors – ease of use, low barrier to entry and simple cool factor are others. Many API publishers have also turned to revenue sharing, hackathons, cash prizes and viral marketing to generate a buzz and enhance adoption.

These attributes are important to any developer, and might be successful in attracting hobbyists and independent developers looking to create useful applications. But what happens when your API’s intended audience is an enterprise? How do you get a large manufacturer, retailer or logistics vendor to allow their internal developers to use your APIs? What do they want and need before they can embrace your API and incorporate it into their IT strategy?

To convince an enterprise to use your API, some of the same developer-centric criteria come into play. The enterprise’s developers need to be able to find the API, understand the high-level value it provides and delve into the documentation of its technical interface. They need secure connectivity to the API and some visibility into its usage once they’ve incorporated it into their apps. API Management vendors like Apigee, Mashery, 3Scale and Layer 7 offer turnkey API developer portals to centralize this information and make it easier to onboard those developers.

But enterprises are wary of setting individual developers loose to register and start using APIs without any client-side governance of this activity. Unregulated calls to various external APIs can have a chilling effect on the reliability of the resulting application. Relying on these apps for mission critical business processes is simply too risky, and enterprises are understandably wary about adopting APIs for this reason.

Similarly, the publisher wants to ensure that their APIs are being consumed by the intended audience in a manner that is approved by their enterprise partners and clients. A robust API geared for enterprise adoption will already have some governance on the publisher’s side – integrated authentication and authorization, threat protection, comprehensive data validation and data privacy and integrity assurance at both application and transport layers. This raises the barrier to entry and puts a burden on client organizations to support the corresponding technology requirements.

Consider an enterprise moving to Salesforce CRM and providing accounts to its sales team. As each individual user goes out and attempts to register themselves, a workflow is generated that identifies the user, validates their corporate email account, notifies a Salesforce administrator at the client company, and then processes their acceptance or rejection of the user, eventually resulting in a working account.

The overhead of managing this interaction – or any similar SaaS or API integration – through an entirely manual process at a large organization quickly becomes an encumbrance. This is why companies like Salesforce provide an API that is geared to the enterprise, complete with Single Sign-On (SSO) integration using SAML. Others provide OAuth-based access control or require incoming messages to be signed with the client’s private key; these solutions all place an additional burden on the client developer, when they should really be managed from a centralized location by enterprise IT.

For Salesforce SSO integration in particular, many vendors sell lightweight connectors that sit within the enterprise infrastructure, integrate with existing Identity and Access Management systems, and provide a centralized point of transit for all outbound Salesforce contact, including automatic provisioning using rules from the identity store. This easy onboarding benefits both parties – Salesforce receives a consistent, secure federated identity that’s being managed by their API consumer, and that customer has full automated control over what criteria (role, LDAP attribute, etc) controls access to an important external resource.

One option for rapidly onboarding enterprises to your API uses a similar solution – a lightweight, easily-configurable point of policy enforcement that sits within the consuming enterprise’s IT architecture and simplifies the integration. This infrastructure can be managed by the API provider and pre-configured to successfully connect the two entities. Sophisticated security and data mapping is all taken care of in a transparent fashion by the gateway, so OAuth handshakes, certificate management, digital signature creation and other barriers to entry are entirely removed. Individual enterprise developers can get back to the basics of reading documentation and writing simple app integration code, and the API publisher gets large partner enterprises on board quickly with assurances of end-to-end security and compatibility.

This type of lightweight API and Cloud connector provides additional benefits to the consuming enterprise. It now has a centralized proxy for enforcement of all outbound integrations, facilitating mashups of multiple external APIs, optimizing internal mobile or web connectivity, simplifying client-side OAuth for developers, caching common requests locally for decreased latency, providing on-premise mock endpoints for testing of pre-production applications and granting visibility into which developers and apps are making use of which APIs.

The goal of a successful integration with an enterprise API consumer should be a mutually beneficial partnership. Enterprises aren’t driven by the same goals as individual developers; they need to have appropriate assurances when including external resources controlled by unrelated entities. This type of architecture essentially extends the governance of an API Management solution to both sides of the relationship – but not every traditional vendor can provide this unique functionality. Only an on-premise platform can really offer the full end-to-end assurance necessary in these partnerships.

For many decades, service providers such as water, phone and cable companies have been deploying physical infrastructures to their customers in order to create a recurring revenue stream as we continue to use their services from our homes and businesses. The deployment of this type of API connector is similar – by rapidly onboarding enterprises that will bring recurring revenue through the use of your API, you can extend your reach and increase adoption and retention of your services. Connecting with your desired audience has never been so easy.

Both comments and pings are currently closed.

One Response to “Getting Enterprises Using Your APIs: Understanding the Challenges and Workarounds”

September 13th, 2012
at 5:27 pm
Comment by: UnblockMySchool » Getting Enterprises Using Your APIs: Understanding the Challenges and <b>…</b>

[...] developer, when they should really be managed from a centralized location by … Read more on ProgrammableWeb (blog) … APIs Challenges Enterprises getting Understanding [...]

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.