This post was originally posted on Forbes.
There’s a recurring trend in the software industry. New technologies are often discovered by people who use them to do amazing things. Others discover and adopt new tech to solve similar problems and innovate further.
Then, a few years down the road, when those technologies have matured and are widely used, other companies attempt to combine the iterations together under a single moniker that will be widely distributed to a much broader audience who had little exposure to or awareness of the technology beforehand. This newer, larger audience then circles back to the parties that have been working with the technologies with a different vocabulary and preconceived notions about the technologies that might not be viable.
When an executive is thinking about creating an API program for their organization, they are likely to encounter Gartner’s Full Life Cycle API Management Reviews and Ratings. In 2016, this category was redefined from “API Management” (largely defined by API gateway companies). According to this definition, the category includes all developer experience needs from API inception to sunset, including:
- API design, development, and testing, including mocking and performance.
- API catalogs with internal and external developer portals and documentation.
- Runtime management, security, and usage monitoring with API gateways.
- Security configuration, API mediation, and API usage analytics.
I would agree that these are critical needs of any successful approach to APIs, but the question should be raised: Is it a best practice for one company to fulfill all these needs? We live in an age where virtually everything has or will have an API. As companies look for products to support these efforts, based on the general “full lifecycle” category definition, they set out looking for a single product that can do everything in the modern software lifecycle—for everything.
The reality, however, is that the API tooling space should be about a connected ecosystem built on open-source standards like OpenAPI and AsyncAPI. The API lifecycle differs in every environment, and the connection points to the ecosystem are based on how those lifecycle stages are defined. As the software world begins to align on some key stages in the API lifecycle, each of those stages defines the emerging categories.
In my opinion, tooling providers should be specialized in some combination of these functions. I would argue that no company can provide a best-in-class experience across all of these functional areas and that buying into a sole provider for everything could mean making huge sacrifices in the quality of experience in most areas.
My company, Stoplight, is recognized in G2’s Summer 2022 report as an industry leader in API Design. Cloudflare is a leader in web applications and API protection. Kong is a widely adopted API gateway solution. 42Crunch and Salt are making big moves in API security. When a customer sets out to research API companies and ends up with a short list including some of the names above, their first question is: Does your platform cover the full lifecycle of API management? At this point, both parties often realize that expectations and approaches need to be recalibrated. Basically, it’s back to square one.
APIs are too big to fit in one box.
The problem with superimposing a catch-all phrase onto the API universe is that it is akin to attempting to describe every software development model with a single lifecycle process.
While there have been plenty of debates over the years about software development models, no agreement or consensus was ever reached because the volume of use and range of circumstances are just too great. As a full-stack programming ecosystem, APIs are now in the same position as software as a whole.
What’s a more realistic view?
Attempts to organize everything API into one bucket may be leading people in the wrong direction. Companies building API programs may benefit from surveying the ecosystem and engaging the original innovators and disruptors who have addressed their particular needs.
When new to APIs, they have an opportunity to maximize their connectivity and interoperability by utilizing open standards such as the OpenAPI Specification. These standards help ensure that the APIs being developed will be able to connect with other APIs and platforms.
API tooling companies, on the other hand, are able to better enable customers to adopt whatever combinations of products best serve their unique API lifecycle by making sure that products are best-in-class and as interoperable as possible.
To buy into the full API lifecycle management view may cause companies to look past the incredible range of solutions that are available to every company and API lifecycle. Take your time and select the tools that make the most sense for your organization in each stage of your API lifecycle. There are multiple solutions that succeed at one part of the lifecycle versus another. To truly scale effectively, combine solutions where possible—and understand there is no one-size-fits-all solution.
