Mike Amundsen recently joined MuleSoft as API Strategy Advisor. Mike is a well-known API expert in the global software engineering community and has authored and co-authored numerous books including “RESTful Web APIs,” “Microservice Architecture,” and “Continuous API Management,” all from O’Reilly. His latest book, “Design and Build Great APIs,” will be available through Pragmatic Bookshelf later this year.
Five years ago, I had clients asking what an API program could do for them. More recently, my clients are asking me how they can leverage the APIs they have now into a successful ecosystem. But a few customers are now looking beyond their own organizational boundaries and asking me how they can monetize and market their substantial API investment and transform their business in new ways.
In my experience, companies can navigate this space in many ways, but the terrain is always the same: make, manage, monetize, and market.
Stage one: make
The first step into the API universe is to commit to APIs as an essential execution element for your company’s IT ecosystem. That means separating the released components (functionality) from the released APIs (interfaces) and creating a program that supports API developers as well as component developers. For some of my clients, this is still new territory.
The notion that APIs need to be designed, defined, deployed, and supported independently of the services behind the APIs introduces not just a new point of view, but also a new set of challenges. For example, a key element of microservice component design and implementation is to establish and honor clear boundaries between components. APIs, however, play a vital role across service boundaries — that’s how we can mix several independent services together to create a company-wide solution. This is what some call API mediation or the experience layer. APIs are the key to realizing the reuse goals most microservice programs are meant to exploit.
Stage two: manage
Optimizing a single API is just the start of the process. The next step (stage two) is the work of designing and supporting an API ecosystem — what Erik Wilde has dubbed the “API Landscape.” This is where many of my current customers are in their API journey. At this level in your API program maturity, you need to shift focus away from optimizing a single API to optimizing your full collection of APIs. And this can be a big challenge for companies.
Here, the key is not enabling service reuse (we did that in stage one). Now the focus is optimizing API reuse. That can be tough when the individual APIs you release are narrowly-focused, single-use designs. Reuse is also problematic if you don’t have a practice of updating and evolving your APIs in a non-breaking way. Finally, the “Golden Fleece” of successful API platforms is a consistent way to apply domain vocabularies that are understood across service boundaries.
Stage three: monetize
Once you have your API platform established, it may be possible to monetize that platform. That means more than encouraging reuse. Now we’re focused on creating new business and new partnerships; ones that reach outside your current corporate boundaries. Note, this doesn’t just mean charging for your APIs. It means focusing on the business contribution of each and every step in your API ecosystem. As you can expect, this represents a whole new set of challenges. I note that very few of my clients are prepared to deal with this “stage three” API world.
There are some notable examples of monetizing public API platforms. Amazon, Microsoft, and Google are the first to come to mind. These companies are successfully selling a general ecosystem of computing and storage — all driven by APIs. Other companies successful at this level are ones focused on a product vertical or channel. For example, Salesforce and Twilio are essentially “category giants” that dominate their own vertical — again all driven through APIs.
At this level, the focus is on solving “other people’s problems.” In large organizations, “other people” could be internal teams at other locations around the globe, other independently run divisions, or even newly-acquired business units. Now the designs need to take into account other vocabularies, other domain languages, and solve other problems besides those of the API provider. And, most importantly, the API platform needs to be designed and managed with the understanding that API users will never meet each other (there are too many and/or they are too far apart) and that the APIs will be used in ways the designer/implementers have never thought of before. That’s a tall order!
I have a handful of customers that are aiming to join this space, but it is pretty early in the going, and success is not assured for any of them. Most continue to focus on cost-saving and reducing risk in their API platform (stage two) and I suspect many will be happy at that level.
Stage four: market
Finally, there’s the stage four API approach. Just as companies learned to monetize their own APIs at stage three, now it is time to monetize the APIs of others. This usually takes the form of an API aggregator, captured platform, or API marketplace. Example players in this space today are IBM, Salesforce, and others. They each offer ways in which you can “buy or rent” services from other third-party providers on the same platform. It’s a kind of two-way market place where providers pay to get on the platform, and consumers pay to use the providers’ API — with the marketplace manager getting a piece of the action from all sides.
Verticals like banking, insurance, and health are ripe for this stage four style of API. But the challenge at this level is to design an API ecosystem that encourages reuse across companies — often when these companies are competitors. The last decade is littered with consortiums and coalitions that failed to cross this bridge and, instead, ended up building the equivalent of stage one (make) style single-use APIs that are not easily modified and difficult to reuse across boundaries.
Looking ahead
So, while most companies focus on getting past stage one (make APIs) and dealing with stage two (manage APIs) some companies are already experimenting with stage three (monetize APIs). And, in a few rare cases, there are companies looking for opportunity at stage four (market APIs). The key is to pay attention to the unique challenges at each level and to face them head-on. The work of optimizing for reusing services (stage one), reusing APIs (stage two), monetizing APIs (stage three), and monetizing verticals (stage four) each requires new technical, social, and business skills.
And knowing where your organization is today and where you want to go is a critical step in making this journey a success for you and your teams.
For more on API best practices, visit MuleSoft’s API strategy page.
