Menu

0Comments

API Management: What CIOs Should Know

APIs hold promise to enhance digital transformations and establish new lines of revenue. From what you spend to how it’s used, programmatic access to data and services is becoming a concern

Advertisement

API Management: What CIOs Should Know

Application programming interfaces (APIs) are fast proving to be significant tools in creating business value for CIOs embarking on digital transformations or seeking to develop new revenue streams.

APIs can translate text, label images, send text messages, check for fraud, retrieve open banking data, and handle an increasingly large variety of business transactions. An API may soon be the way to look up COVID vaccination status. As APIs become critical to their IT and development processes inside the organization, CIOs need to be thinking about management, compliance, and access: who gets access to what company data with what APIs through what governance model?

They also need to consider what the organization is effectively outsourcing — or taking on as dependencies — through APIs. Developers picking an API for purely technical reasons can be making a corporate buying decision or choosing a strategic direction that would otherwise be well above their pay grade.

Policies need to keep API usage under control without impacting agility. This requires a clear view of what internal and external APIs are in use in the organization, what they’re used for, what they cost, and how reliable they are. Strategically, CIOs need to be clear on how APIs contribute to the business.

Advertisement

Integration and composition

“Many of our customers want to go to this future where they actually have an API economy and an API catalog and they expose data across all the silos of their company,” Charles Lamanna, corporate vice president for the low-code application platform at Microsoft, tells CIO.com.

Using an API gateway or other API management solutions with a low-code platform “unlocks tons of opportunity, because developers can build those microservices and publish them for other developers to consume, and citizen developers can consume them via the Power platform,” Lamanna says, by way of example.

But having an “API economy” goes far beyond low code and no code. As Postman CEO Abhinav Asthana points out, organizations need to be thinking about APIs as soon as they start specifying and designing software rather than waiting until the project is finished. “[At the end is] where you make suboptimal decisions, which results in even more compliance and governance risk. There’s no way that if you are building an application today, it is not going to talk to the outside world,” so plan for it from the beginning, he says.

APIs aren’t only for consuming external services; organizations often create their own APIs to offer self-service access to common data within the business or to simplify exchanging information with vendors. Onboarding a new supplier or dealing with a payment query is more efficient if transactional information about invoice payments and shipping status is easily available, but it’s often locked in multiple ERP systems. Creating APIs and publishing them in a catalog can avoid a lot of support tickets.

Advertisement

“Think about data or capabilities that are unique to your organization, that you’re expecting to vend to others, or that simply aren’t available anywhere else,” suggests Miles Ward, CTO at Google consultants SADA. “APIs are the way to connect to information, which is only really valuable when it flows. If you have data that isn’t available via a central, programmable, extensible interface, that isn’t flowing to where it’s useful, it’s time to prioritize that effort.”

Some applications will be built almost completely with API calls. What Gartner calls “composable commerce” is a good example of this trend, says Kelly Goetsch, chief product officer at commercetools.

Composable technologies change the usual enterprise development approach. “You don’t need a team of 200 offshore developers producing volumes of Java code; you want highly skilled plumbers who can get these different applications working together, typically with an eventing architecture and API calls. The more people you throw at something like this, the slower and harder it is to do,” Goetsch says.

What CIOs do need, Goetsch says, is both a catalog of APIs approved and in use, and a comprehensive governance strategy that can be applied at the API gateway that developers use for access, with a common security framework. “Decide which APIs you want to build and which you want to choose from third-party vendors, and the gateway is how you govern access to those APIs for your developers,” he says.

Advertisement

API gateways have often been hardware appliances but that is changing. There are well-known tools for API management and it’s a commodity service on every major cloud with options for service composition, rate limiting, and access control, including endpoint and instance filtering — in many cases down to individual actions on an API — that can provide usage, error rates, and other observability metrics. There are also third-party services such as APImetrics that can track the performance and availability of public APIs.

APIs in the wild

The first step in an establishing a more formal API strategy is auditing what APIs are available and in use. Follow that by ensuring they’re documented and discoverable.

“There’s a lot of repetition in different pockets of an organization,” Asthana notes, suggesting that CIOs involve developers in architecture discussions to raise awareness around API management.

Moreover, APIs already in use can easily be overlooked. One large healthcare organization building an API catalog started with a list of 450 APIs in use: Final numbers were closer to 4,000. Tools that look at proxies and log files and other forensics can find the APIs that already exist in the enterprise and generate OpenAPI descriptions.

Once a catalog has been established, it should be used not just to track the publishing and consumption of APIs but also to create a more strategic policy of API lifecycle management — one that includes dealing with deprecation in the event that an outside API provider makes drastic changes or cuts its service altogether.

Some CIOs are starting to hire API architects and build up API centers of excellence or governance groups to oversee API policy. It’s especially important to track how API usage spreads across the organization, to ensure systems that deliver internal API are resourced appropriately (especially as robotic process automation can create an API from an Excel spreadsheet), and to secure them to avoid exposing data, as happened with services from Bumble and Equifax.

“The vulnerabilities show how much modern apps rely on APIs and how complicated it can be for a company to keep all those APIs private and to lock them all down,” says Winston Bond, EMEA technical director at Digital.ai. “An app built from a swarm of cloud-based microservices, such as Bumble, exposes a lot of connections usually kept safely behind a firewall.”

Cost, trust, and compliance

Another reason to establish transparency around API usage: cost control. APIs are often treated like any other cloud service, but APIs are often less visible and their use is often more unpredictable, which can lead to cost overruns.

“Because the pricing models are complex, they’re based on the consumption and CIOs don’t control how the company is going to consume the application, all you can do is forecast,” says Eric Christopher, CEO of Zylo.

CIOs need to know how much an API will cost in lost business and other disruption if it’s not available, or not operating at normal speed, and who is responsible for any issues that causes. Service level agreements (SLAs) are the norm but they need to be granular enough to cover the APIs you use. Service level objectives, experience, and outcome-based agreements may be more suitable, because it’s the results rather than the connection that matter.

Synthetic transaction monitoring will show operational and performance issues, but far too few API providers offer production test accounts or verify their own documentation, warns David O’Neil, CEO of APImetrics: “How do you actually verify that any of this works if you cannot test anything in production? Your entire production environment could go down and you don’t know about it for five hours.”

OpenID Foundation is developing what it calls “trust frameworks” based on uptime and speed across various regions for APIs in cloud infrastructure, financial services, and open banking, but currently, “there’s nothing out there for public scoring and ranking that’s curated, that everybody in the industry can agree on,” O’Neil notes.

These questions of discoverability, quality, and compliance are increasingly important for APIs in regulated industries such as banking, healthcare, and government services.

O’Neil expects consensus to emerge on how to measure and monitor regulated APIs, from measuring latency to assessing documentation and validating the quality and compliance of API schema. “There needs to be some kind of scorecard metric and a policy group that sets this at an industry-wide level. Some of the things that are happening with APIs are going to be global, transnational things that need to have an agreed set of standards behind them,” he says.

A 2021 priority

API lifecycle management is still nascent in many organizations, according to Dion Hinchcliffe, vice president and principal analyst at Constellation Research. “The cloud-native movement is definitely making microservices and containers a first-class citizen in IT, and last year was a turning point for Kubernetes with IT, so 2021 is shaping up for one where all of these questions are starting to be asked seriously and more widely at the CIO level,” he says.

Unsurprisingly, regulated industries such as financial services and healthcare are furthest down this path, Hinchcliffe says. One top US healthcare network already sees a quarter of its revenue coming through APIs and expects that to grow to more than half in the next couple of years. With revenue potential like that, “API design, selection, management, governance have now suddenly become C-suite issues,” he says.

CIOs who leave business departments to manage all their own software and technology will have the least visibility into API usage, Zylo’s Christopher says. “Where CEOs are saying, ‘Your job is to know everything that’s happening in the business and get in and make those departments run better via technology’; that’s where you’re starting to see API understanding and visibility.”

“As a CIO, I’d like to know, ‘These are all my external dependencies, these are all my internal dependencies, and this is how they fit together,’” Postman’s Asthana says. “Having that gives a lot of leverage: I know how to staff my engineering teams, I know what building blocks are available, and I can set the roadmap for those things much more effectively.”

The converse is also true, Asthana warns: “My belief is that if you’re still not understanding that all of these things are coming and the solution lies in an API strategy, then you could have a lot of problems. You can look at it as a developer productivity issue, as a regulatory issue, or a privacy issue: All of these things have solutions in an API strategy.”

Do you have a story that you think would interest our readers? write to us editorial@cio.co.ke

Advertisement