An application programming interface (API) defines the correct way for a developer to request services from an operating system (OS) or other application and expose data within different contexts and across multiple channels.
Beyond the nitty-gritty of programming with APIs, once it has been developed and published, an API offers point-to-point connectivity between business processes that span internal and external systems. Some connect to operating system services or microservices, while others act as a gateway to access complex business workflows.
For instance, a food producer may surface APIs covering traceability, ingredients and stock taking units (SKUs); a supermarket might use these to manage stock levels in its distribution centres; then APIs from logistics providers might be used to ensure orders from the food producers are shipped seamlessly to the distribution centres by having a script that automates reordering based on a threshold level of stock.
In the business-to-consumer space, an internal API might tell an e-commerce site if stock is available and ready to ship, an external API might provide payment services, and another might connect to the shipping provider to enable the courier to send out tracking information directly to the customer.
Often referred to as the glue that binds applications, web services, operating systems or smaller application components together, an API is written to a required syntax and is implemented by function calls composed of verbs and nouns. In practice, developers can harness prebuilt functionality, through their APIs, to speed up software development or access OS services, or submit or request data from an enterprise application.
For those unfamiliar with the jargon associated with computer programming, to surface the API, a software developer needs to create a function call, which has been designed to receive certain parameters, such as data values. These pieces of data provide the API developer with flexibility, allowing functionality to change based on the parameters fed in. Some work in a one-shot mode, such as “change traffic lights to green”, but more useful are the APIs to functions that return a value such as “what is the status of the traffic light?”.
The good news is that developers do not have to be experts in the technical details of how and why the API works. It is only necessary to know three things: that the API exists and what it does; what parameters it needs; and what values it provides back to the program that invokes it.
Armed with these, a developer can access OS services, read and write data the correct way to and from enterprise data stores, and gain access to advanced technologies for applications ranging from internet of things (IoT) and edge computing to artificial intelligence (AI) and even quantum computing.
While APIs do not represent a new concept, it is important that IT decision-makers clarify which APIs are internal and available to the teams developing software, and which are external and available to internal stakeholders and possibly external partners if there is a business imperative to open up API access.
Analyst Gartner defines five areas of API management, covering developer enablement, business alignment and key performance indicators, as well as API lifecycle management and API gateways that provide controlled access to APIs. The analyst firm urges IT leaders to score their organisation’s maturity in each of these areas, with a range from “non-existent” to “optimising”, to help them decide where they need to focus.
In the Gartner paper, What are the three steps for a successful API product?, analyst Carolin Zhou recommends that IT leaders determine where their organisation wants to be in the future by defining its most critical business goals, determining the organisation’s current and long-term business goals from its leaders, then creating API use cases.
“IT teams need to engage business stakeholders to determine where APIs are needed, providing use cases to senior management and other decision-makers to demonstrate the value of APIs,” she writes in the report. “When building the business case for an API and securing executive support, you should think of the API as a product, not a project. It helps to appoint an API product manager and create an API platform team. This will help generate enthusiasm for using API products to enable business agility and speed to market.”
After determining which APIs are needed, Zhou recommends that IT leaders look for the gaps between the organisation’s most significant API use cases and its business goals. This may include automated service-level monitoring capabilities, compliance requirements or similar functions. “These gaps are opportunities for you to build these APIs with a product approach and a roadmap in mind for continuous improvement,” she states.
Gartner recommends organisations fill in the gaps discovered by mapping measurable API use cases into their business goals. As Zhou notes, IT leaders should think about how their APIs can contribute to these goals, and then translate them into metrics they can use to measure value, such as quality of API design, number of API calls and the like.
The analyst firm’s research around the importance of aligning the API strategy to business goals reflects the findings of a recent study from Mulesoft, which has begun using the term “fusion teams” to describe how business and IT people with differing skillsets are collaborating.
According to Mulesoft, to address process challenges brought on by the worsening economic climate, senior IT leaders are looking to create fusion teams aimed at tackling inefficiencies. These are multi-disciplinary teams that blend workers with technology, analytics, or domain expertise, and who share responsibility for business and technology outcomes.
“Shifting economic headwinds are making technology even more fundamental to success across every part of the business, including sales, service, marketing, commerce and IT,” says McLarty.
Research published by Mulesoft, based on a global survey of 1,000 IT decision-makers, found that 69% of organisations have created or are in the process of rolling out fusion teams, and an additional 22% plan to do so within the next 12 months. Mulesoft found that in organisations with fusion teams already in place, almost two-thirds (63%) of IT leaders say these teams have helped the business meet its goals.
Mulesoft’s survey reports that the majority of senior IT leaders believe data or systems integration projects take too long (66%) and are too expensive (69%). At the same time, more than two-thirds (68%) recognise that a lack of data or systems integration creates a disconnected customer experience. Nearly all (98%) of the senior IT leaders who took part in the Mulesoft study say new investments are influenced by a tool’s ability to integrate with existing technology.
While not every organisation has a dedicated API team, the role of the API product manager is gradually being formalised, recognised and popularised. According to Alessandro Chimera, director of digitisation strategy at Tibco, API development is being democratised and expanding to become a more ubiquitous discipline and skill.
“In many ways, the challenge with APIs is a human one. APIs are fast to implement and (when built carefully and conscientiously) execute their functions quickly and succinctly,” he says.
Chimera believes this shift also requires people to adapt. He says this is because using APIs effectively requires a new way of thinking about partnerships; a new way of thinking about collaborating, connecting and coordinating.
For instance, using APIs for data access reduces the level of ongoing maintenance that developers need to perform. For example, software developers can eliminate the tasks associated with installing and upgrading drivers, or relying on unsupported drivers to make their applications work.
Access to data can also be simplified, according to Jeff Carpenter, engineering coach at DataStax, who says data services remove the burden of programmers having to maintain their own data access or abstraction layer. “Using APIs rather than direct connections like object-relational mapping (ORM) removes a significant source of complexity required to just get things working as your team wants.”
Carpenter says another big benefit of using APIs to interact with data is that the programming team can use the style of API that they are most familiar with, such as REST, gRPC, or document-based. This reduces the learning curve to get started with managing data and keeps the team focused on developing the core business logic of your applications.
From an API strategy perspective, Mulesoft’s idea of a fusion team is a key ingredient to success, especially if the data exposed by the API requires specialist knowledge, which can create a barrier in terms of the expertise needed to use an API.
In a recent interview with Computer Weekly, James Fleming, director of IT at Francis Crick Institute, discussed the challenges of sharing medical research data across different organisations globally. On the one hand, virtual private network (VPN) access is probably the most basic means to enable researchers to access a remote file store. The other extreme is API-based access, which can offer a very granular level of programmatic control.
However, Fleming says that while APIs work well if the data being accessed is well understood, the vast majority of research data does not fit into this category. Beyond scientific research data, there are bound to be numerous examples of esoteric internal data stores that make little sense to someone outside the organisation. Does access via an API make sense, and if it is deemed necessary, what level of expertise is required by the programmer to use it correctly?
Beyond the need to have domain expertise to get the most out of developing APIs for others to use, Bernadette Nixon, CEO of Algolia, believes in the idea of having an API-first strategy. This means thinking about APIs at the onset of the development process for new products and services. For Nixon, an API-first strategy offers organisations flexibility, speed and backward compatibility.
From a flexibility standpoint, she says APIs should be designed to handle a broad range of use cases, which is the opposite of what a product or platform provider does. In terms of speed, Nixon says an API needs to handle the velocity of intense throughput and application “calls” without developers having to worry about performance tuning.
Looking at backward compatibility, she adds: “Organisations that want to offer an effective API have to think about backward compatibility. This is so that developers are not stuck carrying out grunt work on maintenance tasks when they should be building front-end functionalities.”