APIs may seem like the domain of developers, and in many ways, they are. APIs have a small footprint, so they’re a useful tool for calling services or data and one reason why we can have so many cool apps on mobile devices.
But APIs are very much a business issue, too. Here are three reasons why the CIO, other IT executives, as well as business leaders, should be involved with API discussions:
1. APIs can be used as a business strategy. APIs can allow you to connect with customers or partners in new ways, either by opening your own data or offering your own apps. For example, GM recently created an API development kit and portal to open up its infotainment systems, which is now built into GM vehicles. But deciding which business strategies and goals to support — that’s a decision best left to the business leaders.
You can also imagine the risks of rolling out an API that opens up something that your company’s executives don’t want opened up.
2. Integrating new channels and mobile devices. A 2012 Vordel survey found that the top two drivers for enterprise APIs are integrating new channels and offering mobile applications. Deciding what channels and identifying what business goals are best served by a mobile app are both business-level discussion.
3. Not all APIs are ready for business. Ross Mason, CTO and founder of MuleSoft, warns in a recent Wired piece that the API landscape is very wild.
“I have personally worked with a lot of APIs and my experiences have ranged from joyous to stab-myself-in-the-eye bad,” Ross writes. “This is in part because not all the information is readily available—very few vendors publish SLAs or their track record of meeting SLAs—but also because the landscape is completely disaggregated.”
What that means, he explains, is that you’ll need to assess the API based on:
- Your service-level agreement requirements
- The viability of the vendor
- The near- and long-term costs of using the API
- Comparing competitors
While a developer could do that, it’s a bit outside the job description and involves judgments best made by a division manager, an enterprise architecture or someone who deals with the big picture on a daily basis.
But that doesn’t mean you should shut out the developer. As Ross also points out, some API landscapes cater better to developers than others. So you’ll need your developers’ feedback on how much support and documentation an API will have for development. This can also serve as a way of assessing an API’s “readiness.”
