I thoroughly enjoyed Daniel Jacobson’s talk at Mashery’s BAPI this year and have shamelessly borrowed a quote from one of his slides as a permanent fixture to my Outlook signature: It takes nearly three years of public API requests to equal one day’s worth of private API requests
Hot on the heels of this Daniel posted a very thought-provoking blog, Why you probably don’t need an API strategy and it was this post that reinforced my own position and gave me some ideas on how to better articulate this notion of strategy and tactics in the context of APIs. If the reader hasn’t guessed already from the title of this post, my view is slightly contrarian.
First, there is a surface point here, which is that I obviously work for one of the top tier API management vendors out there, so in one sense I am “part of the problem”, but there is a deeper point here about strategy and APIs that I want to explore.
As Mashery, we routinely talk to the Fortune 50 about APIs. These are some of the the largest Enterprises in the world and for this audience, the commonplace definitions of “strategy” and “tactics” are a bit too coarse. I argue that with an updated notion of strategy there truly is an interesting way that APIs fit into the business strategy of any organization, large or small.
There is one assertion that Daniel makes which leads off the distinction, which is “If there is an API strategy then it means that API is the product in-and-of-itself.” Part of my disagreement here is that this assumes that the only time when an API is strategic is when it is offered as the core product. That is, it acts as a rigid designator and actually is the business. I think this is necessarily correct, but there is more to the story.
Let’s peel the onion and get to my version of strategy
What is Strategy?
As a company positions its products and services in the market, there are two key elements of strategy, a strong offense to attain a competitive market position and then the capabilities and resources to defend the source of its advantage against rivals. In this framework I hold the view that the Netflix API is an isolating mechanism, not just a ‘tactic.’ The Netflix API is actually a core part of Netflix’s strategy – it’s part of the defensive aspect. In fact, any API with a large enough developer community is a defacto isolating mechanism. Want to take on Google in the mobile space? Part of the difficulty here is not just the O/S or phone, but the developer community who has invested in the platform.
With API management, the defensive aspect works exactly the same way – developer communities and the level of usage and engagement are absolutely strategic.
What about the offensive aspect? Here it’s not just about a long term plan, but it is about increasing the customer’s willingness to pay by providing more value in the form of buyer’s surplus. What is buyer’s surplus? Buyer’s surplus is that feeling you get when you get a really great deal, or purchase something for a lot less than you could have, or would have. Happy hour provides a lot of buyer’s surplus, as does Ikea, or Trader Joe’s.
So the first move here is to accept a richer notion of strategy with two dimensions – an offensive, value driven piece, and a defensive piece. In other words, equating “product” and “strategy” with “non-product” and “tactic” is too coarse of a distinction. We buy Apple iPhones vs Microsoft Phones (sorry Microsoft) and Tesla Cars vs Porches (sorry Porsche) because they provide the most economic surplus for the price (from the buyer’s perspective) compared to the competition.
Degree of Modularity
In the last section I covered the first way in which APIs are strategic – as a defensive mechanism.
The second way in which APIs are strategic is even deeper and draws on the notion of interfaces. Let’s adopt an equivalency between “APIs” and interfaces, and quibbles aside assume that RESTful APIs today are the closest (and best) expression of a universal interface. The next question concerning strategy, for any corporation is what goods and services and activities happen inside the firm and which goods, services and activities happen outside the firm. This distinction holds for all firms, but applies best to those that thrive in a digital economy. The lemonade stand can’t benefit from RESTful APIs, yet.
This is a key strategic decision that relates directly to the value proposition. Another way to state this issue is to ask the question with a software interpretation of the organization: Where in the stack do we open interfaces? Here the “stack” is the entire organization, including its supply chain, manufacturing, marketing, sales, e.g. the whole enchilada. In software engineering we call this the degree of modularity of a software system, but now we are applying the notion to the firm itself.
The notion of strategy here is that the firm can open new markets, create new distribution channels, engage partners & customers by deciding where in the stack they will innovate themselves and where they will allow others to innovate. This allows firms to focus on creating buyers surplus rather than investing in non-core areas. There is a pretty good list of customer examples here.
In this sense, interfaces and the placement of interfaces are absolutely critical to strategy, for both offense and defense.
In Daniel’s case of Twillio, this is the degenerate case example because the company is itself an essentially an interface. I think this is what Daniel meant when he equated product and strategy. I think APIs have enabled a lot of interesting business model possibilities and am curious about what the future will hold.
Internal & Partner vs External APIs
If we take the discussion to the next step we can also ask, are all APIs equally strategic? Perhaps internal APIs are less strategic than External or Public APIs. Perhaps Open APIs are the ‘most’ strategic. This commonsense notion also has to be addressed.
Almost Anything that can drive costs out of the IT system is strategic because it allows the firm to lower prices. What happens when prices go down? Buyer’s Surplus goes up… and that is exactly what Internal APIs do – they facilitate sharing and capacity reuse internally. Partner APIs both reduce costs and provide a way to engage new suppliers, and Open APIs allow the widest possible net for innovation. In this sense all three are strategic.
I think the future for APIs (or ‘Enterprise Interfaces’) is a bright one and am eagerly awaiting what the future will bring.