Service providers delivering through the cloud need to realize there’s more than one way to generate revenue. Most start focused on delivering end-user services and that’s all well and good, but there’s money to be made from value-added services. APIs should be on the “must have” list from day one to enable third-party developers to build new applications around core services.
Even API service providers are guilty of thinking “services first, APIs later,” according to a blog piece at API Ware. Digital assets need to be defined, broken down into the most useful smallest possible resource pieces available, and then made available as a API service that can be used to build web, mobile, and any other types of applications that can be built.
MuleSoft CTO Uri Sarid says interoperability needs to designed in at every stage of the process, citing Uber’s success at both using a third-party API for billing and providing an API for use by third-party mobile apps. The API expands the value of the app while bringing more business to Uber, resulting in a win-win for developers and Uber.
Bigger, inaccessible services only frustrate developers, while APIs providing granular access and more building blocks and opportunities for third-parties to leverage the already existing investment in cloud. Smaller API building blocks enable more opportunities for developers to incorporate services into their larger applications. Without those hooks, there aren’t any opportunities for expanding the use of cloud services to grow market share or to generate incremental revenue.
And if you are going to go API-friendly, everyone says self-service is the obvious way to go. Let developers find and use what API services you have and be able to access them at will, rather than setting up artificial barriers to prevent. Service providers need to deliver real-world examples of API applications and SDKs for ease of use. Providing those resources make it easier for developers to rapidly tap into cloud services and build apps on top of them.
Examples are the best sales tool for developers, as it provides them with a clear way to understand API functions and how they can be incorporated into larger projects. Marketing materials and specifications are well and good, but they don’t provide how a service can be utilized, while reading documentation takes too long unless developers are already invested in a project. Incorporating APIs should be easy enough for developers to quickly try.
Speaking of quickly try, a free “sandbox” and development accounts for experimentation and initial building testing are a near standard feature these days. Developers want to take features out for a test drive before committing larger amounts of time to build revenue apps. A sandbox increases the time a developer spends with API services, thereby increasing the likelihood that more developers will move from curious prospects to active revenue-generating partners.
The mantra of accessible services fits into the wider developer community credo of open course, where everything is available for use and easy to extend and build applications with. By being open, everyone in the user benefits, with service providers gaining customers and developers getting access to the best tools more quickly than having to build their own or have to wrangle their way through licensing and wading through documentation before they can even get access to services they can work with.
Access to APIs from day one when rolling out services means viewing developers as customers to be catered to, rather than as an afterthought on the back end. Service providers need to recognize that while developing and making APIs available may take some more effort on the front end, it dramatically increases the ability to build third-party support and more revenue generation once services go into production.
