When thinking about how to use APIs in your tech stack, there is a lot of confusion about what exactly a comprehensive API strategy entails. If you ask five executive leaders what they mean by "API strategy," you are likely to hear a variation of these responses:
-
Exec Leader 1. “What are we doing with microservices, modernizing our apps and APIs?”
-
Exec Leader 2. ”I mean the strategy to publish our APIs externally to partners. What are we doing to target low-touch developers? Or to enter new markets?”
-
Exec Leader 3. “We must adopt API-first and API as a Product. So, how are we helping our internal product teams to adopt API-first and to become API enabled?”
-
Exec Leader 4. “What metadata are we collecting to help with API discoverability, operational excellence, and to drive business reuse discussions?”
-
Exec Leader 5. “What's our strategy for a self-service high-velocity environment for providers and consumers of APIs? Single source of truth for API specs, documentation, support, knowledgebase?”
Creating a multidisciplinary API strategy
To address the diversity in how different executive leaders think about an API strategy, I created a diagram that reflects the comprehensiveness of the question itself.
Like an iceberg, there are many aspects of an API strategy that are hidden. For an API strategy to succeed, it needs to establish a multidisciplinary program that orchestrates multiple areas simultaneously, with a laser focus on achieving the highest business outcome.
You'll note that the tip of the API strategy iceberg simply shows the outside-in business development and digital transformation that is a result of a thorough strategy.
Underneath the tip are elements or disciplines that make up a full-fledged API strategy:
- Product-centric enablement: This includes strategy around API as a product, product owners and product management alignment with the API strategy, API business and value metrics, and an API products marketplace.
- Developer enablement: This area of the strategy is concerned with self-service, high-velocity API provider and consumer workflows, forums, notifications, SDKs and libraries, and low code/no code solutions.
- Lifecycle management: A comprehensive API strategy must include a discipline on lifecycle management, including API taxonomy implementation, discoverability, versioning, testing, documentation, reuse workflows, and a vendor strategy.
- Application architecture: This includes strategy related to design best practices, domain-driven design, microservices, Async APIs, and application stack modernization.
- Compliance and security: Strategy here relates to the API inventory, access control policies, centralized gates, enterprise-wide processes, monitoring, and observability.
Aligning your API strategy to your business strategy
Many companies treat an API strategy as a technology initiative without business alignment—the end up talking about the tip of the iceberg, even as they struggle with the low-level capabilities. For this reason, it is a crucial step from the very beginning to align your API Strategy goals with the company’s overall strategy.
This is easily said, but it is not so easily done without the proper executive sponsorship and alignment.
This is not a unique struggle. In talking with peers from different companies, I’ve found that many struggle with the same business alignment issues, no matter the industry or the size of the company. On the other side, only a few digitally savvy companies have successfully achieved a "no ambiguity" status and can clearly define the desired business outcome of their API Strategy.
Most business execs don't really care about APIs per se, they care about high-velocity solutions.
Reaching this business alignment will drive the API strategy to realize its value and to focus on where to play, where to invest, and where to win.
Moving from project to product without an API strategy is risky
Let me share one scenario to demonstrate a certain risk related to your API strategy. Going "from project to product" without aligning the product owner role with API strategy could eventually hurt the overall business agility.
Pursuing the journey of "Product-Centric Enablement" without understanding or aligning to the API strategy can create an impasse with the autonomous teams that were empowered to improve internal processes. Such teams can turn into islands if they are unable to integrate with other products to compose new innovative solutions or to meet increasing business requirements to meet the speed of the market.
APIs are a foundation of digital transformation, like layers of Lego pieces and ready-made components, supporting high-velocity solution creation, multi-experience development, and participation in relevant ecosystems. Poor alignment with an API strategy would negatively impact these outcomes.
Defining product boundaries can be tricky. Moreover, a simplistic view of an autonomous product doesn't address the multiple layers of capabilities and the numerous types of integrations required within an enterprise. The taxonomy within the iceberg of an API strategy allows for managing these multi-layer capabilities and for a mesh of products to compose new innovative solutions. It's like a team sport where no one product is expected to own all end-to-end experiences, but to contribute to winning solutions and capabilities that the market will imagine and demand in the future.
Conclusion
From what I've seen, in the absence of a coherent, well-understood business alignment, an API strategy could still deliver on partial outcomes of the iceberg, perhaps achieving the "Compliance and Security" goal or the "Application Architecture Modernization" goal. These are good places to start small, but they are by no means the full realization of an API business strategy in the digital business transformation journey. Creating an API strategy that fully aligns to your business strategy is the best way to achieve both.
