You have probably heard of organisations declaring they are API first – everyone must design and deliver APIs as part of their daily duties. When asked, most will cite API reuse as the primary reason. However, not all organisations reach this goal. Instead, they end up with an API catalogue of 1000s of APIs, each with no consumer or perhaps a single API consumer.
Let’s explore why API reuse is difficult to achieve and how organisations can shift their understanding of API reuse to improve the success of their API program.
The unattainable goal of API reuse
An API-first culture focuses efforts on digitising an organisation’s capabilities using APIs. Each time a new solution is built, it starts with designing and building one or more APIs to support it. Teams are encouraged to design service-based APIs with the intent of delivering reusability. Over time, the portfolio of APIs continues to grow. However, API reuse is limited to a few select APIs, while the remainder has a single consumer.
You can observe how reusable an organisation’s APIs are simply by browsing the list of available APIs and noting how many are consumed by more than one consumer. The greater the number of consumers per API, the more reuse that API has experienced. For most organisations, only a few APIs have more than one API consumer (usually < 1 percent of the total number of APIs).
So, why is it that this goal of API reuse is rare? Typical reasons include the following:
- Focusing on service-based decomposition rather than delivering outcomes via APIs, resulting in a catalogue of fine-grained services that are fit-for-purpose.
- An emphasis on team-based delivery models focusing on delivery efficiency rather than reuse.
- Assuming that every API will offer some level of reusability but ultimately discovering that this isn’t the case.
Let’s learn more about the types of API reuse and then examine how we can shift our focus toward a digital capability-centric approach to take advantage in different ways.
Understanding the types of API reuse
“We must build APIs for reuse” is a phrase often encountered in today’s digital transformation initiatives. The challenge is that reuse can look different depending on whether it is internal or external to the organisation. API reuse can also differ if the same API is to be consumed by the same team or by multiple teams. Therefore, it is important first to understand the types of API reuse:
Fit-for-purpose APIs
This is often the case when building connectors between new and legacy systems, transforming data from a legacy data store, or integrating with a third-party system. Experience APIs and APIs designed for a specific partner integration also fit into this category.
Inter-Domain reuse
This focuses on reusing an API within a specific business unit or domain, often by reusing service-based APIs. The focus is often on sharing a particular behaviour or digital capability specific to the domain and not applicable outside of it. It helps to accelerate the delivery of solutions by one or a few teams within the same domain area of the organisation. The result is localised reuse rather than global reuse.
Platform-level reuse
Helps developers across the organisation benefit from the API. Teams across the organisation can discover and consume the API to save them time. APIs at this level compose a reusable platform of digital capabilities that developers across the organisation can leverage for building solutions and bundling them into API products.
Product-level reuse
Bundle one or more APIs into a branded, documented, and supported offering to target specific personas and market segments. Organisations focusing on platform-level reuse can bundle their existing platform APIs into products to leverage economies of scale. Business partners and customers leverage these APIs for frictionless integration, often in a self-service model.
You can categorise your API portfolio based on each type of API reuse. It may be eye-opening to realise that you have more fit-for-purpose APIs than you thought. Or, you may have an API platform that, until now, has gone unnoticed. If you notice more fit-for-purpose or domain-level APIs, it is time to shift from a service-centric approach to a digital capability approach when designing your APIs.
API reuse through a digital capabilities approach
Digital capabilities are assets that turn desired outcomes into reality through automation, and they support a digital interaction model across the workforce and may help partners and customers. Digital capabilities are the assets that drive and support your organisation’s business capabilities by producing outcomes for one or more personas.
Examples of digital capabilities include:
- Pre-qualifying applicants for a credit line
- Assessing risk as part of an underwriting process
- Climate controls for an automobile
It is important to note that digital capabilities are not just APIs that deliver raw data. Instead, they focus on delivering desired outcomes through a series of activities performed by machines and/or humans. In addition, digital capabilities make significant boundaries when seeking to organise teams. One or a few teams then own all aspects of the API operations and associated data. These teams can become hyper-focused on delivering outcomes as efficiently and effectively as possible.
Review your API portfolio and identify the digital capabilities they offer. If most of your digital capabilities provide raw data rather than delivering desired outcomes, you may have spotted some opportunities to grow your API portfolio.
Discoverability drives reuse
If developers can’t find your API, they will build it themselves, and API reuse will be an ever-moving target. For mid-to-large scale organisations, you need an API catalogue to organise your APIs for discoverability and reuse.
An API catalogue is a library of APIs that your organisation owns. Catalogues support internal developers by allowing them to browse, discover, and use any available API. It also allows developers to locate APIs that are still a work in progress, preventing a team from building a duplicate API when another team is already delivering one.
An API catalogue is different from a developer portal. A developer portal focuses on API products, and it is a branded and curated list of APIs with associated documentation that targets specific personas and/or market segments. Contrast that to an API catalogue, which organises and provides structure across all your organisation’s APIs. API catalogues organise while developer portals productise.
Targeting API efforts in the right way
Nearly every API strategy starts with the idea of reusability. Yet, API reuse is a challenging goal to achieve. By understanding the levels of reuse available, developers and product managers can better target their API efforts in the right direction.
This should be combined with delivering digital capabilities that produce outcomes through activities rather than a service-centric approach to API design. Finally, ensure your APIs are discoverable by anyone in the organisation through an API catalogue. These steps will help your organisation to realise your goals of API reusability.
