"API First" is a term that is used with increasing frequency as one important aspect of the larger Digital Transformation concept. Digital transformation has three main pillars: business, organizational, and technology. Interestingly, "API First" plays into all of these pillars and thus is a great way to not just crystallize thinking about digital transformation around something a bit more concrete, but it also makes sure that you're not missing one of the three important pillars that make or break digital transformation initiatives.

The Three Digital Transformation Pillars

Before we describe in more detail what "API First" means, let's briefly look at how it plays into the three digital transformation pillars mentioned above.

• Business: API First means to embrace APIs at the business level, and to understand that while APIs are not the only important aspect of digital transformation, they are the products that you create, manage, sell, measure, recombine, and retire. API First means that if a product in your organization does not have an API, it essentially does not exist. APIs are the connective fabric that allows your organization to create value and to be able to quickly adapt your value chains in response to internal and external feedback.
  ‍
• Teams: API First means that all teams embrace the fact that whatever they create has to be delivered through an API. It also means that teams understand that API quality establishes an upper threshold for product quality: No matter how good your service or product is, if it is delivered through a bad API, this substantially diminishes the quality of the product. Essentially, the organizational aspect of API First is to understand that as a result of digital transformation, organizations become easily reconfigurable meshes of API-delivered services, and anything that compromises this vision is problematic for long-term success.
  ‍
• Technology: API First means that everything that gets created or consumed in the organization is based on APIs. This means that the quality of APIs greatly matters for how easy it is to create and consume things, how useful the choice of technologies is for the kinds of products delivered through APIs, and how much they are designed not into the void, but with specific use cases and scenarios in mind. In addition, since the goal of digital transformation is to have a mesh of loosely coupled components that can be adapted quickly, it becomes essential to think about how easy it is for APIs to change without creating expensive and time-consuming ripple effects through a chain of API dependencies (if you disrupt API chains, you disrupt value chains).
  ‍

Now that we have established how "API First" plays into all three pillars of digital transformation, let's have a closer look at what it means in practice. First and foremost, it means that everything produced and consumed in the organization is an API.
‍

API First Principles

This may still be pretty high-level, and raises the question of how this general statement can be put into practice. As s starting point, it is possible to look at how this translates into three aspects of where the API literally comes first:

• API as first UI: Each product gets designed with its API in mind. The API is the first UI in the sense that it defines and limits the kinds of interactions that a product supports. Concrete UIs that are later built may only use parts of the API, or they may combine various products into one UX, but in terms of pure product capabilities, the API is the single source of truth.
  ‍
• API before Implementation: Designing and discussing APIs should be done before implementation starts. Early prototypes with possibly limited functionality should be produced as quickly as possible, but even before that sitting down with potential users and discussing design options and preferences can be extremely valuable. With the right iterative approach the API can grow in an evolutionary manner (adding more features over time as they are requested). As a general guideline, always discussing designs before implementing them helps with creating more user-friendly APIs.
  ‍
• API Documentation: Since the API is one of the essential aspects of all products, documenting it becomes important. While the level of documentation depends on intended audience size and how much the Developer Experience (DX) of the API is thought to be a deciding factor, documentation should be seen as an essential part of each API. Structured documentation such as API labels can help to document APIs in a more structured way, so that growing and evolving API landscapes are easier to understand and manage.
  ‍

These aspects make it a bit easier to understand where investments are needed when moving towards API First: Teams have to embrace the fact that APIs become one of their main deliverables, and the organization should support them with platforms and tooling and should also build discovery and automation around the growing landscape of API products. In fact, APIs are the contract that teams promise they will fulfill, and developing the product then becomes contract-driven development, where the team's goal is to fulfill the contract by delivering a product that behaves as the contract (the API) is documenting and promising.
‍

All Products are APIs

Speaking of products, the fact that teams now are always producing APIs means that focusing on the API always is important. There are two ways to look at that, and while the first one (API-as-a-Product) currently seems to be a popular perspective, the second one (Product as API) actually is the one that better reflects the ultimate goal of Digital Transformation and API First:

• API-as-a-Product: This term is often used in contexts where the main thinking revolves around monetization of APIs. While this can be useful, it also should be kept in mind that directly monetized APIs are a small fraction of the ones that organizations are using. In the vast majority of cases, the value of APIs isn't in direct monetization, but instead in the ability of the organizations to create, test, deploy, adapt, and retire value chains quicker than before. For this reason, while API-as-a-Product is a legitimate worldview for a small slice of APIs in organizations, it is advisable to not primarily focus on direct API monetization.
  ‍
• Product as API: This term embodies the essence of digital transformation where each product (i.e., each capability produced by the organization) is an API and is used through its API. This view highlights the fact that the utility and the value of products is directly related to their APIs: If they have no APIs, they cannot easily contribute to value chains, and if they have poor APIs, their utility may be diminished because of this design issue. In summary, Product as API makes it clear that every product in an organization must be conceived, designed, and delivered as an API.
  ‍

In summary, "API First" is one of the essential concepts in digital transformation. As we have shown, it encompasses all three pillars of digital transformation. It can be seen as a useful blueprint for how teams approach their product journeys, and it also serves as a reminder that each and every product is represented by an API.

The "API First" message is an important one to establish in your organization. It anchors the sometimes abstract concept of digital transformation in something more tangible, and also results in a direct call to action for everybody in the line of business: Always focus on creating a good API for each and every product. APIs are the contracts between all product teams (and with external partners as well), and managing digital transformation means managing this interconnected mesh of contract providers and contract producers.
‍

OK! APIs! But what do I do now?

Embracing the concept of products as APIs is a great first step to move towards a better foundation for Digital Transformation. But what does that mean in practice, and what are concrete steps to make it happen?

In practice, the hardest part is to go back to the three pillars mentioned above (business, teams, tech) and to make sure that the API focus is established and embraced. What that often means is to make sure that product ownership and product management are enabled and coached and supported on their transition to an API-centric product view. While API products are still products, they do have some special aspects to them, most importantly a faster rate of change, and there are many of them with complex interdependencies. This makes the roles of product owners and managers a bit more challenging, but also provides them with new opportunities.

The first step in the API First journey is to establish this new model of API products, and not just at the tech level. API products are a little special, and everybody in the organization needs to understand why and how, and how it affects their roles. This is probably the most challenging aspect of digital transformation and APIs as its representation a the product level: help everybody to understand what changes, how they can adjust, how they are supported, and what new opportunities this enables.
‍

Conclusions

API First is a relatively straight-forward concept. But it's a hard concept to enable and establish and support in organizations, because it does change some of the more traditional perceptions of what products are, and how to manage them. Make sure to always think about how the change of product focus affects everybody in your organization, and how you can help them to make the most out of the new API focus. This needs a clear API strategy and program, and enablement and coaching to make sure that everybody is aligned with the new product model. If you make sure to establish these foundations, you will be able to reap the benefits on the API first approach.

‍