Daniel Jacobson, Director of Engineering for the Netflix API, wrote a timely and provocative article: Why you probably don’t need an API strategy. I read one response, and I'm sure there are others, offering a different perspective on strategy.
When we see a trend like API Management, clearly in the early part of its hype cycle, and with its associated buzzwords now commonplace in mainstream IT, this generally means the idea has crossed the chasm from cutting-edge technology companies to the rest of the enterprise world. In other words, CIOs and CMOs of non-technology businesses are getting interested in open APIs, and API technology providers (including RepreZen) are targeting this interest.
So I read this discussion about Strategy vs. Tactics in a certain light: for companies outside of the IT sector, just how much enthusiasm is warranted? What exactly are we going to do with APIs, and where does that fall in the tactical-strategic continuum?
When I talk about non-IT companies, I mean those businesses whose primary products and services do not consist of data, content or computations delivered over the wire. As the article points out, these companies won't usually offer APIs as a primary product. Depending on the industry, their external APIs may be focused on product catalogs, inventory, logistics, configuration, pricing, specialized transaction processing, and information supplemental to the product or service. In that last category, supplemental information, think about product manuals, configuration-specific engineering diagrams, service histories, etc.
If you're Netflix, a big percentage of your IT iceberg is above the water line, exposed to partners and customers. If you're Amazon, you started with private, internal APIs; eventually exposed these APIs to retail partners; and then, strategically, exposed an entire platform for services, along with new APIs to manage that platform.
It's this evolutionary path that I want to talk about. For most enterprises, SOA is an iceberg with a smaller tip. Your IT organization has APIs, often in large numbers, often used only by a single department or a cluster of related systems, and almost always closely coupled to individual services that expose them. These are private APIs, the submerged portion of the iceberg.
But increasingly, there are opportunities and incentives to expose APIs. You may expose them securely to partners, customers and suppliers; or you may expose open APIs to the public. Economics drive this. With the growth of big data technologies, and with new standards and initiatives around open data, the utility of public, linked data is growing exponentially. With REST-style APIs as a de facto standard for internet services, the barriers to participation in specialized marketplaces, collaborative communities, and innovative SaaS platforms are getting lower.
What's needed is a strategy, driven from inside the IT organization, to align with these opportunities, and position the enterprise for faster, cheaper emergence into the semi-private and public API space. This is about technology and architecture. We need to design and build our internal APIs and, just as important, their supporting data representations, to participate in the public API ecosystem. We can't reliably predict where the best value for external APIs will be. But it's a safe bet that the API economy will open real possibilities for customer engagement, sourcing, operational efficiency and market presence.
Many of our services won't ever cross the organizational boundary, but that doesn't matter. There's no reason to maintain an architectural mismatch between internal vs. external APIs. Services are bound to cross that line in ways we can't predict, and the internal cost of integration, already way too high in most organizations, is even higher when services are designed to different architectural paradigms.
So, which APIs do we modernize first? What's our path from the intranet to the public cloud, and what infrastructure do we need to buy or build to get there? How can we hit the moving target of standard, REST-style API design without locking ourselves in? Where does it make sense to maintain internal data formats, and how do we map these to industry standards?
This is the stuff of strategy. Maybe not at the enterprise level. But from the perspective of a CIO, CTO or CMO, these decisions, collectively, need to be organized as a coherent, large scale program, whose successful planning, coordination and execution is critical to the business. I call that strategic.