Just like any product, APIs have their own lifecycle with distinct phases. And recognizing them means you can take advantage of them by focusing on the right aims and the proper convenance at each step along the way. This was one of the key lessons we focused on when we wrote the “Continuous API Management” book in 2018.
There are situations when you need to invest lots of time and effort to get an API product ready for consumption. At that time, taking shortcuts or skipping critical steps will likely to result in poorly designed, hard-to-use APIs that fail to realize their intended value.
At other times, mature APIs that are returning consistent value need to be “left alone.” Instead of spending valuable time and resources making changes to an already successful API, the product should be optimized and tweaked in small ways to maximize its value for the company without requiring substantial investment.
Finally, like all products, APIs will eventually outlive their usefulness and deserve to be granted an end-of-life plan, and eventually removed from the system. Not all APIs reach their intended usefulness and no API lasts forever. Removing unused APIs from your system will eliminate clutter, improve maintenance efforts, and often reduce infrastructure costs. And that frees up time, effort, and money for creating new APIs that can contribute to your company’s overall long-term success.
Let’s take a look at each of the five stages in depth to see how they contribute to a complete continuous API management experience.
Five steps from create to retire
Like any product meant to be consumed, APIs go through an overall lifecycle from inception to retirement. Here’s the model we found captures the key stages of API products:
Create
At the start, APIs go through a design, prototyping, and test phase. APIs at this stage might even be “complete,” but they haven’t been released into production and are not considered available for wide use. While in the create phase, the interface is likely to change, exhibit errors, and experience periods of non-responsiveness while you work out the details and handle the edge cases.
It is important to have an active design process for your API products — one that includes a business rationale for the API itself. Designing, implementing, and maintaining APIs in production is a costly endeavor. Doing all that work without a clear use case (and way to measure success) can lead to needless expense.
Several companies I work with offer “Design Thinking” and “Product Management” courses to their API and services teams to expose them to common patterns and practices in the product space. While it is not important for programmers and team leaders to become fully-versed in general product management, knowing the basic concepts can help your API staff recognize and capitalize on common patterns and principles that lead to well-designed products that solve an identified business problem.
Publish
In the second stage of the lifecycle, the API is placed into production and made available (e.g. via access controls, portal publishing, etc.) to one or more developer communities for use. At this point, the API is considered reliable, the interface is stable, and the proper security and scalability elements are in place.
Publishing an API is more than just pushing it onto production servers. Making an API public likely means investing in documentation, training courses, sales materials, and even staffing up support forums and online communities. Wide adoption of the API can hinge on whether the publishing effort was adequate for the target community.
Just as public-facing APIs can benefit from people dedicated to developer relations or product advocacy, internal-facing APIs — especially in large organizations — deserve the same types of release activities to help realize their stated goals. I know more than one organization that maintains a dedicated internal marketing efforts to make sure the APIs released into the company’s ecosystem get proper publicity, support, and use-tracking of its production APIs.
Realize
Once an API product is released and available, it goes into the phase focused on realizing the initial reason that product was created. In this phase, you might change the interface to better meet your goals, tweak performance, availability, scalability, etc. All these changes are driven by the desire to realize the initial purpose of the product.
Good APIs solve a problem and a good API program keeps track of just how well those APIs are doing at solving their stated problems. The work of realizing an API is actually the work of “proving” that the API product is doing a good job solving the problem it was designed to address. That means you need a clear way to track the APIs behavior and compare that to the planned results documented during the create phase.
Taking advantage of the realize phase of an API requires a good API monitoring program. You need clear metrics, too. For example, if you design and publish an API to help boost completed new orders, you need to track metrics like number of API calls to the close-order endpoint, number of errors, number of closed orders per day/hour/minute, etc. Of course, you also need a baseline for these values before you even release the API!
Comparing your before and after metrics on an API product can help you understand how to improve the existing API and how you can do a better job in the future for other planned API products in your organization.
Maintain
Assuming our API meets our intended goal — it is realizing it’s planned value — you can eventually place it into “maintenance mode.” At this point, you should focus on getting the most value from the product without investing a great deal in changes to it. You may do some minor optimizations, (look for ways to reduce operational costs, etc.) but it is important to resist making any major changes or costly investments to the product. Essentially, you’re just counting the repeated incoming revenue (or cost savings) the API was designed to produce.
It is important to identify when the API reaches the maintain phase since that will affect how you judge whether it is worth it to invest more time and effort into changing it. Placing APIs into maintenance mode means you can dial back on adding new features and focus on improving performance, reducing operational costs, and maximizing return. This is the peak phase of any product life -— the phase when all the early work pays dividends. If you’re lucky, this phase can last a long time as your API continues to contribute to the success of your ecosystem while demanding minimal effort from your resources.
Retire
Finally, as the realized value starts to wane, as the operational costs outweigh the revenue/saving benefits, it is time to place the product into retirement. You may begin a program to migrate remaining users of this product to a new, more valuable, alternative or — if the service is no longer needed, simply work out an end-of-life plan for the API and begin the “wind-down” process. Retiring an API frees up resources (infrastructure, staff, support, etc.) and helps to clear out little-used parts of the ecosystem.
It is all too easy to forget about actively managing the retirement phase of your APIs. But ignoring unused APIs can lead to needless costs in infrastructure and support. And that means you’ll have less money for new, important API products in the future.
I know companies that have discovered APIs that have not been actively used in many months. One company found close to 20% of their production APIs had seen no activity in the last 90 days! Yet these APIs were still hosted on cloud platforms, some running in high-availability mode, and adding to monthly operations costs.
There are lots of reasons an API falls to disuse. It may have never had a significant use base, it may have been replaced by a newer/better API released somewhere else in the ecosystem. Or the problem it was designed to solve has been rectified and the API as outlived its usefulness. For whatever the reason, a regular process of reviewing traffic and identifying APIs that need to be placed into retirement mode is important for any healthy API program.
Managing continuous APIs
API product lifecycles help us see that, like all products, APIs go through phases and each phase has its own challenges and requires unique solutions. Creating APIs focuses on testing theories and making changes to meet goals. Publishing APIs means properly documenting, scaling, and publicizing the product to the proper communities.
APIs in the realizing phase require constant monitoring and measuring and often undergo updates and changes to “dial-in” on reaching the goals set out in the create phase. And, once the product has matured, it can move into the maintain phase where the focus is on optimizing performance and maximizing yield. This is the time for minimizing changes and reducing new investment on the product.
Finally, as the APIs use wanes in the organization, it is time to go into the retire phase where an end-of-life plan is introduced. The remaining users are ushered into newer products and infrastructure resources are scaled back. Eventually, once there is no longer any meaningful traffic, the API product can be taken out of production thus freeing up resources for important new products in the future.
And then the cycle begins all over again. To learn more about the product management practices of APIs, check out the “API-as-a-Product Workshop,” one of MuleSoft’s API Program Workshops.
