After countless visits with customers, clear patterns emerge in how API programs and digital transformations take shape. One clear motif we’ve seen: almost all customers use the results and learnings from their initial projects in a program to inform their API roadmaps.
This is true whether it’s an experimental “proof of concept” API implementation, or the first in an already carefully planned series. Organizations also use these results and assessments to help create alignment organizationally, and build the case for APIs and the benefits they offer.
We’ve observed the best results when customers work with both first- and second-order metrics. For example, with a “consumption” enablement API—one that enables a new mobile app to use data from an existing back-end SOAP service, for example—first-order metrics might show the number of applications deployed against the APIs, the daily traffic against them, and the number of developers using them.
A first-order metric: API traffic reports
Second-order metrics, which are composed of "derived" dynamics, might show developer engagement, or monthly revenue lift resulting from the use of APIs and the way they enable new forms of corporate resource monetization.
A second-order metric: developer engagement
Consumption APIs are relatively simple to instrument, particularly if you are using an API platform that makes it very easy to get at both first- and second-order metrics. But other types of APIs might be trickier to instrument. For example, a very common first API project is some form of single sign-on, or the creation of a security model that will be used for the rest of the API program implementation.
So if an organization’s first API implements a “secure perimeter” within which additional APIs will subsequently be implemented, it might be a little harder to quantify the value returned from the project. But one needs only to look in the news almost any day to see evidence of the catastrophic enterprise costs of security breaches; there are plenty of studies that estimate these costs and the frequency of incidents that occur.
Another approach is to estimate the downstream costs per project resulting from not having a secure perimeter and uniform security. Each of those projects will have an implementation cost for the security model, and the sum of these can be compared to the cost of just doing it once.
Hopefully those who have championed and driven an initial API project to completion can, one way or another, quantify the benefits and take a moment to sit back and breathe a satisfied, “we made it, and look at the difference.” If this isn’t you, there are many Apigee resources that can help, including Apigee customer support and the Apigee Institute. To be able to do so requires forethought and planning, and the appropriate choice of technology stack and tooling so as to make the results as visible as possible, with the least work.