The API economy is well and truly upon us, according to Gartner research director Gary Olliffe. But the journey to the composable enterprise is not necessarily a straightforward one.
Application programming interfaces (APIs) "have been elevated from a development technique to a business model driver and boardroom consideration," noted Deloitte's Tech Trends 2015 report.
"Public APIs have doubled in the past 18 months, and more than 10,000 have been published to date," noted the Deloitte report, which was released in March.
"The revolution is also pervasive: Outside of high tech, we have seen a spectrum of industries embrace APIs—from telecommunications and media to finance, travel and tourism, and real estate."
Whether enterprises decide to implement APIs to open up a set of capabilities to internal or external audiences (or both), the investment needs to be aligned with business objectives, Olliffe told Gartner's Application Architecture, Development and Integration Summit in Sydney last month.
API programs should be led based on business objectives and there needs to be some way of assessing the value that an API is delivering to customers.
Olliffe's key advice was for enterprises to adopt a "product-centric mindset" for APIs: Treat them as a product being delivered to a market.
"APIs are the way we stitch together what I call the extended enterprise," Olliffe said.
"Your enterprise is in the middle of this. Your enterprise is delivering its core capabilities, but if you look at your dependencies on other service providers, on business partners, on customers, cloud service providers — you currently have interfaces to them.
"They may not all be API-based today but they're trending in that way at a very aggressive pace, because we're decoupling the consumption [of services] from the provision."
APIs can open up a business' capabilities to internal customers, partners or external customers, or some combination.
"It may simply opening our capabilities to our peers and colleagues within the organisation to reduce the inertia around accessing a particular set of data or particular capability, so that they can work on their own pace," Olliffe said.
He said he has witnessed a significant number of organisations enabling business application delivery with an API
"They're delivering the API as part of an application delivery initiative," the analyst explained.
"They're mobilising their existing capabilities. They're delivering new HTML5, single-page architecture Web applications, using the API as the mechanism to connect back to those business and data resources."
Typically organisations will not initially treat an API as an asset but as the deliverable of a project, he said.
However organisations that go through that process can end up realising that an API has value in its own right.
APIs can go from being used solely for application delivery to driving new revenue streams or reaching markets that may otherwise be untapped.
Product or project?
Businesses should not take a "project-centric approach" but instead run API delivery as a program, Olliffe said.
"You need to have roles and responsibilities that take on that product management, that reach out and understand what the consumers of that interface are going to want from the API," the analyst said.
The product approach extends to planning for an API's lifecycle: "You need to operate it over its lifecycle: This is not a case of once-and-done projects where, you design, you build, you deploy and you're done...
"Once you deploy a service that's being consumed by a marketplace of consumers you have a responsibility to those consumers to continue to provide the level of service that you committed to, to continue to support them as you evolve and enhance that service, and to provide them with stability."
"APIs should have the clarity of a well-positioned product—a clear intention, a clean definition of the value, and perhaps more important, a clearly defined audience," said Deloitte's Tech Trends report.
"Is it a small set of known developers, a large set of unknown developers, or both? What is the trust zone? Public, semi-private, or private? How do these essential facts inform the scope and orientation of the service?"
A go-to-market strategy for APIs
Whether it's delivering capabilities to customers through an API rather than through a manual process or exposing capabilities to a new collection of business partners building their own business models, organisations need to understand who they are targeting, Olliffe said.
And as with any product, a good customer experience is a must. Developers should be treated as first-class citizens. But although it's developers who will interact directly with an API as end users, a team that aims to deliver an API as a product shouldn't just be made up of developers.
"It needs to include business stakeholders," Olliffe said.
"You are ultimately going to be delivering business capabilities to an audience, and you want to make sure that your business objectives for that API program align with the business objectives of the enterprise as a whole."
And as with any product, it needs to be marketed, he added.
"You need to evangelise and deliver the message to that market," he said.
"Whether that's your internal developers and communications through internal channels, whether that's promoting it to an audience of external developers, whether it be a partner ecosystem or local development partners through hackathons or through participating in meetups and conferences — you have to have a go-to-market strategy
"You need to be putting effort into promoting it to the audience that you want to be using it."
Because an API should be aligned to business objectives, an enterprise needs to be able measure if its meeting those objectives, Olliffe said.
"You need to have some way of gathering insight that tracks back to business value," he said.
The metrics used to measure this will depend on the particular set of business objectives.
For example, it could be the number of users employing applications that interact with the API, traffic driven through to a particular service, direct revenue, an increased partner network, or access to new channels or markets.
Effective design for an API requires a user-centric approach. Enterprises need to understand the personas of the developers who will use an API and let that influence design choices.
Thought needs to be given to the commitments made to developers. For example what service levels will an enterprise guarantee, what fees (if any) will be charged, and what kinds of commitments are there regarding data submitted via the API?
The level of support offered to consumers of an API needs to be enough to enable them to be productive.
In Olliffe's view, at the very minimum developers should be able to access documentation, a sandbox to test code, code samples, platform SDKs and a community to offer exchange ideas and obtain support from peers.
A developer portal is an important way of engaging with the end users, the analyst said, citing Twilio's as a good example.
The most successful APIs are those that have very efficient self-service provisioning and access capabilities, Olliffe said.
"That self-service might only extend to that developer service level — it might extend beyond that ... there needs to be some self-service means of gaining access to that service, so that the developer can confidently experiment with it and determine it's the right service for their particular business scenario," the analyst said.
Finally, enterprises need a versioning strategy for APIs, he said. In general, organisations with developed API programs try to version external APIs as little as possible — so it's important to that an API is designed with scope to evolve without breaking existing uses.
Follow Rohan on Twitter: @rohan_p