Three Horizons of Your API Journey
For nearly 20 years, every business that uses software has been on a journey to API adoption. This path toward APIs has become the lingua franca of the application development world, with APIs as the primary way that technology interacts and transacts.
As I laid out in a recent post, the framing of the API adoption challenge has stuck too closely to the now-dated narrative of monolithic, all-in-one platforms, which are jacks of all trades and often masters of few. Mirroring the cloud native application trend and empowered by “shifting left,” developers, site reliability engineers (SREs), DevOps and platform engineering teams have pushed back against this top-down approach to an API solution.
Cloud native technologists are instead choosing to build their own API stack suited to their needs. These stacks combine open source, proprietary and in-house products to craft a sustainable yet malleable set of solutions for managing the rapidly growing number of APIs while accelerating API development.
As organizations adopt the API stack, they often follow a similar journey. This journey can be mapped as a framework of sorts with three distinct horizons. Each horizon represents a series of problems, processes and practices that most organizations will need to work through as they evolve their existing infrastructure.
Horizon 1: Getting Off the Ground
At the first horizon stage, organizations are just getting their feet wet with APIs. For the most part, technology teams are using APIs on an ad hoc basis to connect to external systems. This may either be to bring in more efficient external services or as a nod to the reality that partners and customers expect to connect and interchange information via API.
This first stage of API adoption is characterized by inconsistent — and at times, disorganized — API practices, where the organization may only be adopting APIs out of necessity. Engineers at this stage are focused on handling north-south API traffic, establishing connections and enabling communication between external systems. The design emphasis is on integrating APIs with existing systems, such as third-party services or external partners, to facilitate data exchange and enable functionality across different platforms. Usually, architects are not yet deploying microservices or Kubernetes and likely are not using fully distributed systems.
At this immature stage, engineers usually have not standardized API design principles — different teams may be building their own infrastructure (deploying gateways, basic security, etc.) without communicating their decisions. This often leads to impromptu approaches to meet immediate integration needs, which can subsequently result in technical debt.
Horizon 2: Setting Flight Path
Continuing the journey to a full API stack, the second horizon of API adoption is characterized by the creation of an organization-wide API strategy. Usually, this means the company has recognized that APIs will become an essential part of their architecture, treated with the same care as application development, databases, networking and security in terms of planning and resources. Stakeholders (developers, DevOps, SREs, platform ops and security and networking teams) in this stage recognize the need for a structured and cohesive approach to API management across the organization.
At this stage, north-south APIs are a critical part of the application stack and east-west APIs become a growing concern. The company is likely adopting some (or many) cloud native application constructs, including microservices or serverless and potentially distributed container orchestration systems. The need for standardization comes from the recognition that the company is moving toward an API-first architectural posture. A growing concern is managing internal APIs and giving developers tools to design, build, deploy, manage and secure internal APIs in a loosely coupled manner.
Microservices are often a catalyst for this stage. Teams separate monoliths into smaller applications that can be independently developed, deployed and scaled, with the microservices linked and managed via API. This decomposition allows for better maintainability, scalability and agility within the system. Engineers in this stage focus on designing APIs that align with the organization’s overall architectural goals, promoting reusability and enforcing standardized practices for API development, documentation, security and versioning.
Horizon 3: Escape Velocity
At this point, an organization has a developed and rapidly maturing strategy and approach to APIs. Stakeholders have graduated from acknowledging API-first as important to making API-first a priority for operating. Engineers in this stage adopt an API-first approach to development of any new application or upgrades to existing applications. APIs are designed and developed as part of the application and architecture planning process to integrate tightly with underlying systems, infrastructure and backend or data applications. This approach emphasizes the importance of well-defined, well-documented and reusable APIs with the goal of deploying them as the foundation for scalable and interoperable systems.
At this third horizon stage, teams establish comprehensive approaches and governance for all types of APIs, including internal, partner, third-party and (if applicable) public APIs. These governance practices ensure consistent API design, security, versioning and life-cycle management across the organization, enabling efficient collaboration and integration with external stakeholders. Ideally, much of this is automated with baseline schemas set for API creation and policy types for different APIs classes.
Because the API stack is flexible and loosely coupled, this horizon stage is where the platform ops team should evaluate new technologies that could help their organization improve their API systems — new formats like GraphQL, generative AI tools for automated and updated documentation and languages like Denon that generate API-friendly code out of the box.
Beyond Maturity to API Stack Agility
Once an API program has crossed into the third horizon, then the critical mass is usually sufficient to keep momentum going. APIs are not just mission-critical, they are the foundational technology architecture of the organization. Developers, DevOps, SREs, security, and networking teams all have become stakeholders and are bought in. Platform ops teams now see APIs as a key part of their mandate and a key component for the ongoing success.
The beauty of the new API stack is that it also makes it easy to change out components or modify approaches without major disruptions or downtime. All the cloud native conventions of agility can be applied to APIs, including A/B, blue-green and canary deployments. After reaching the third horizon, you’ll have the agility needed to handle any twists and turns in the API journey ahead.
