Most companies aspire to be platform providers, and APIs will get them there

Software really is eating the world. Close to two-thirds of organizations in a recent survey report they have become -- or seek to become -- not just companies producing products, but also platform providers. 

That's one of the takeways from a survey of 350 IT managers released by Cloud Elements, which finds 62% of organizations aspire to become platform providers to integrate with partners, maintain stickiness with customers, or find new revenue opportunities. 

So what does it mean to be a platform provider? Alex Moazed of Applico provides a nice definition of what it means to make this transition: "a business model that creates value by facilitating exchanges between two or more interdependent groups, usually consumers and producers.... Platform businesses don't, to use a common phrase, own the means of production- instead, they create the means of connection."

That's the ideal, at least -- though it's unclear how many aspiring platform providers will throw out their inventories in favor of just being a connection point. What is clear, however, is they see APIs as critical to making the connections needed to attain this new business model, opening up online assets to partners, and vice-versa. Fifty-five percent of the respondents to the Cloud Elements survey say API integration is "critical" to their business strategy, and an additional 29% said it is "somewhat critical." 

Of course, Cloud Elements is an API integration company itself, so naturally they're going to trumpet these results. But, objectively, the survey data also provides interesting perspectives for those seeking to build their business capabilities on an API architecture.    

APIs are now part of the development process for most. Nearly 55% are using APIs to build B2B products, 36% for mobile products, 29% for B2C/consumer products, 26% for employee productivity, and 22% for IoT applications. CRM applications are the most likely to be opened to API integration (24%), followed by finance (16%), ERP (15%), database (12%), communications (10%) and human capital management (6%). 

Of course, developing an API-driven platform takes time. Development teams take 41 days on average to build a net new API integration with advanced capabilities, the survey finds. Respondents plan to build 18 integrations on average in 2019, up from 11.5 in 2018.   

"To be successful in this new API landscape, it is important to establish principles and practices that move beyond simple API functionality and lean toward safe, effective, and scalable integration without slowing the pace of innovation or adding unnecessary costs," says noted API evangelist Mike Amundsen, quoted in the Cloud Elements report. He advises concentrating on three areas: consistent API design, delivering action-oriented APIs, and reducing the costs of change.  

In terms of API design, API creators should "document their work in a consistent, measurable, and reusable way," says Amundsen. Gather user stories, and employ  "Agile, Scrum, and other less formal models all include some mix of interviews, observations, and surveys to gather data."  Ultimately, the final API design "then gets turned into a general description  document," which "can be rendered in a formalized machine-readable format like ALPS, DCAP, JSON Home, and other formats. Lastly, the output from these activities is tracked within DevOps pipeline tools and the results are posted on dashboards where anyone interested can see them."

Action-oriented APIs include experience-based APIs.that cater to specific end-users, APIs expressed as events or structured messages, and hypermedia-style APIs that "return not just data but also metadata -- instructions -- on how to craft queries and update operations on the fly."

Finally, changes in APIs need to be addressed through forking to run new versions in parallel with older versions, or simplying message passing between services. This is important, Admundsen says, because "as API programs grow, and as APIs increasingly become dependent on other APIs, the practice of burdening API consumers with the bulk of the change costs does not scale."