Why API management is so complex

The interconnected nature of cloud-based software applications relies upon Application Programming Interfaces (APIs) to ‘glue’ many of the disconnected and distributed streams of this new world together, but why is managing APIs so complex and such a burden?


Software applications are interconnected. Almost every piece of software we use takes the form of an app that has the potential to connect to other applications, data streams and functions as well as internal (in your PC or on your device) and external third-party IT services.

This interconnected reality was less true prior to the millennium (remember when a web browser came on a DVD-ROM disk that you had to install?); that was a time when a PC did often stand comparatively alone, it’s only ‘connection’ being to the company file server for saving and backup, or to access the occasional shared spreadsheet.

But that was then and this is now… and now, cloud-native web-centric mobile-first software is massively connected to other entities, often via an Application Programming Interface (API). APIs have the ability to 'speak' to and ‘glue’ together application elements and services together. They are written to a required syntax and are implemented by what are known as function calls composed of verbs and nouns.

All well and good then? We’ve built the web, we’ve built the cloud, and we’ve built a set of conduits to interconnect all the neural nodes that exist inside the current notion of what manifests itself as a modern IT system. Yes and no, i.e. all of those statements are true, but APIs turn out to be expensive to develop, tough to keep consistent control of, and complex to track in granular detail.

That’ll be $30K per API, please

Axway CITO Vince Padua suggests that currently, it can cost in the region of $30k on average to build an API, taking more than half of enterprises weeks or months to do so. Padua’s firm develops an API management platform that aims to shoulder all the tricky tasks associated with looking after API activity, calls, robustness and security.

“Organizations need to establish a solid API management initiative where reuse, centralized governance and visibility are key,” said Padua. He says that API complexity arises for reasons such as different security requirements across different cloud instances, the trouble organisations have when attempting to scale up their systems, and the issues that arise on the cloud migration journey itself.

Equally vocal on this subject is MuleSoft, which in Spring of this year introduced the latest major release of its Anypoint Platform for API management. The company claims to be able to give software application developers a way to discover, access and serve data from multiple existing APIs with a single query, without writing any additional code. The Anypoint DataGraph allows users to create what the MuleSoft is calling ‘composable business capabilities’ formed with a connection to a variety of API sources.

What composable business capabilities means in this sense is a combination of: a) some modern cloud-native application data services channeled by APIs as the conduit as well as b) some connections to legacy services that have been rehosted in cloud as ‘lift-and-shift’ operations.

White noise on the API radio

But we’re still only halfway through the battle. The data that powers the new digital services being created naturally lives in a lot of different systems (MuleSoft’s Connectivity Benchmark Report 2021 found that the average enterprise has over 900 applications).

In many cases, APIs have long and complex responses – and are often designed so that they return every field, including the ones the programmer (and, ultimately, the user) don’t need. This often means developers end up writing custom code just to parse through and extract the data that’s needed for each new project, so as they start to work with several APIs at a time – that process doesn’t scale and a lot of the efficiency gains from reusability are lost.

“We’re already past custom code. We’ve moved into the world of reusable APIs, which is a great start, but still limits us to only being able to connect one API at a time. MuleSoft is setting its sights on enabling businesses to reuse multiple APIs at a time, with a single request and no additional custom code,” said Shaun Clowes, SVP of Product Management, MuleSoft.

How does that work? Well, Clowes explains that APIs often have relationships with one another, which enables them to be conceptually stitched together to form a graph of all the data and capabilities they contain. That means that developers don’t need to spend loads of time doing shallow data extraction work – they can just query the data they need from the graph, and get it.

DataGraph means that, even though the demand for data from more systems is constantly growing, integrating more systems doesn’t require more effort. Developers have more power to create leverage from what exists – without understanding all the complexities and relationships that go behind it, and architects and IT admins have fewer APIs to manage and secure.

A vast universe of future APIs

Looking further ahead, MuleSoft believes API management has to be massively scalable — not just accounting for the number of APIs, but also the variety that will exist. Future businesses will run on a vast universe of APIs with many ‘transports’, architectural patterns and deployment environments. The months ahead will see firms in the API management space build tools to get APIs discovered, managed, governed and suitable for reuse.

“We will help catalog and manage every API — no matter where it was built, or where or how it’s deployed. We will launch an ultra-light gateway, built on open standards, purpose-built for containerised microservices environments. We will make creating event-driven systems easier, by using APIs to describe asynchronous, event-driven transactions. And we will provide a unified monitoring, security, management, and governance control plane,” concluded Clowes.

Like all good things, APIs come to an end. Or more specifically in this case, APIs come to meet their end-of-life terminus. When an application use case is closed down, when a data service find itself subject to a change of governance, or when any wider IT system that makes use of an API is no longer in use or made redundant in some way, then APIs also need to be securely retired and shut down.

You may not meet anyone with a formalised business card job title that reads API Manager, but API management is a core skill that every IT department will now need to consider. Plus anyway, like DVD-ROMs, business cards are very 1999, right?