In 2002, Jeff Bezos issued what is now known as the API mandate: ‘The new direction at Amazon is that all capabilities will be designed and exposed as APIs’. This is an early version of what is today called API-first. The growing maturity of cloud, with its virtually unlimited processing power, and the reality of Big Data combined with the impact of Covid over the last two years has pushed us ever faster into the digital economy and an API-first approach.
There are a number of reasons that a company should build APIs into its technical roadmap, including:
- The migration and rationalisation of legacy infrastructure into a single, simplified environment. This includes scenarios where they may be already two or more API Platform instances in play.
- The never-ending search for efficiencies and oversight over national and multinational distributed operations.
- The streamlining of communication with employees, customers, partners and suppliers.
- The monetisation of assets and capability.
However, there is little point in building out an API based organisation unless there is a proper understanding of what it is to be used for. In fact, we recommend an approach that is 50% technology and 50% creativity, whereas the ration in the traditional approach was nearer to 80/20.
Establishing a road map
Getting the maximum value out of APIs and their platforms requires an up to date understanding of their utility and detailed lifecycle management. It’s important to understand the existing technological landscape and how APIs will complement and enhance it. Deploying an API infrastructure is not like throwing a tablecloth across a surface; it is usually built out use case by use case.
It’s essential to build an optimum technology stack which focuses on the interplay between cloud, API platforms, data and security as part of the planning process. There are many API platforms in the marketplace, and in the initial phase of an API project, there is often a debate between open source and proprietary products. In some cases, it does make sense to kick off with a low-cost open source ‘trial’ platform. However, while a short-term investment in open-source tools and “good enough” point solutions will deliver similar immediate results to complete technology stacks, this changes over time. Choosing the most suitable proprietary product – one that allows commitment to a road map – enables companies to take advantage of product innovations without serious retooling or business change.
Building a strong foundation
In a large geographically distributed organisation, there is often a degree of resistance to the implementation of an API-first approach. There are many reasons for this, but the most common are difficulties with departmental silos, and getting buy-in from technical leadership that has an established and functional modus operandi. Change is hard, and the inevitable centralisation of technical infrastructure that an API-first approach brings may not be in everyone’s immediate interest.
One of the major drivers for initiating an API-first programme is the rationalisation of legacy technologies into a single, unified containerised environment. This can be achieved through the use of APIs that can then be used to manage the overall infrastructure and its associated connectivity. Though this is an easy statement to make, the reality is that existing systems and data may be in a variety of forms and repositories that have been procured over many years, or acquired through acquisitions.
A good starting point is a detailed inventory of all the existing infrastructure, and then a build out of a detailed plan with a full appreciation of the risks. The plan should clearly articulate the end state, the reasons for consolidation and the expected gains. It then needs to be communicated and discussed with all stakeholders. In a large organisation, a project of this nature may take months or years to implement. Systems should be decoupled from each other, rationalised and given API interfaces that are easily discoverable, understandable and usable.
Making management easier
An API portal should remove friction and instantly answer questions. It should allow for an ecosystem for developers to “play” with APIs and imagine how they can further extend their business capability with the innovation that is made available. The days of taking weeks and months to onboard developers and partners for API access are over. They need timely access to both internal and external APIs, and the support of a community to understand how to derive efficiencies and/or value.
Generating value
Though many API-first programmes start with internal rationalisation, the advent of the digital economy means that many organisations are looking for new routes to customer engagement and incremental revenue. There is often significant value in the information an organisation holds on individuals. An example of this could be information that goes into a Know Your Customer (KYC) credit rating application. Though this kind of activity is subject to GDPR/POPIA legislation, making it available can generate significant revenue.
Another way in which APIs are being used to generate value is by providing the front end to system output. An example of this is the growing trend to provide remote AI-based medical diagnosis using unloadable X Rays and other medical artefacts.
APIs for external, monetisable consumption need to be corralled into a portal/catalogue which makes their discoverability and an understanding of their value straightforward. Another option could be to expose API capability on one of the growing number of API marketplaces such as Rapid API or Prompt API, though given their size it may be necessary to guide potential customers onto and within these facilities.
The caveat is that successful API-first programmes do not invent or run themselves. They need to be carefully conceived, planned and managed with an eye to the meaningful and realistic objectives. This takes leadership, foresight and courage and, sadly, there are too many examples of projects that were well conceived that have failed in execution.