Creating an API-First Culture and Company, Part 1 – InApps 2022

This blog is part of a 4-part series.

1. Creating an API-First Culture and Company, Part 1 (this post)
2. Creating an API-First Culture and Company, Part 2 (coming soon)
3. Manage Your APIs Like a Four-Star Restaurant (coming soon)
4. How Platform Teams Should Think About APIs (coming soon)

Perhaps the biggest shift in the technology world over the past decade is the rise of the Application Programming Interface — the API. This is because the API is the underlying enabler of many other massive shifts: SaaS, cloud computing, container orchestration, distributed applications, serverless computing, and even machine learning. APIs make the continuous modularization of technology possible, if not inevitable. The idea that the programmatic interface of a structured digital service is a tech stack’s lowest common denominator has become so well-baked into software engineering that, for many types of functionalities, developers would never dream of writing their own libraries and services.

Considering how APIs have become ubiquitous and essential, we anticipate future big winners being API-first companies that embrace the API as their products’ core or as a key element in how they go to market. Some enterprises are obviously API-first because the API itself is their primary product. Twilio, Stripe and Plaid are three popular examples of this business design. But other organizations could still be classified as API-first because their culture and ethos demand that everything be consumable and addressable via APIs. Amazon, Google and Facebook fit this description.

That said, the vast majority of companies are not tech giants nor are they API-as-a-product innovators. Yet, the winners and losers in every sector are now determined largely by their facility for technology and software. By extension, those companies should be comfortable with APIs and transitioning toward API-first thinking and business practices. A question we often think about at NGINX is, “How can companies create API-first cultures and transition to being an API-first company?” This is a central consideration as they evolve their existing technology stacks and move toward more cloud native, distributed application architectures where APIs play an increasingly prominent role.

We Are in the Third Wave of the API Economy

In the API economy’s first wave, we witnessed the rise of APIs as a way to pull key functionality into applications. Facebook, Twitter and Google Maps all illustrated how developers saw the huge benefits of adding functionality to apps by pulling in API feeds. In the second wave, we saw the rise of API-as-a-product companies like Twilio and Stripe. These giants validated the ability to sell a critical service as an API to be embedded into other applications and services.

Today, we’re in the third wave. The third wave of the API economy is the decomposition of many core internal and external business processes into microservices and small applications fronted by APIs. The APIs become the primary method by which businesses use technology to share information, streamline processes and otherwise improve business logic.

APIs enable new markets while also empowering faster and more economical ways to reach existing markets. APIs also allow for better internal utilization of technology. This is driving microservices and a broad — perhaps even more radical — shift away from messy monoliths to a better scaling and more agile “Jobs to be Done” (JTBD) approach. A JTBD framework enables broader ownership inside of organizations. Services can have owners and small teams, codifying the “two-pizza team” concept as a primary creation mechanism in enterprises and making work reusable for building new products and capabilities.

Creating an API-First Culture and Company

Realistically, creating an API-first culture and company is a journey that requires consideration and groundwork. There are multiple steps — from design and rules of API structure and development, to prioritization and planning for the right type of infrastructure to support APIs. The most important part of this journey, however, is a mental shift. API-first companies take this mental shift to heart, making the API their primary product. All other products spring from the API. Anything the API exposes facilitates downstream applications and use cases.

Phase 1: Envision and Evaluate

Step 1: Create Guiding Principles for the Ideal API-First State

You probably don’t want to dictate terms to developers – this rarely goes well. But you can and should lay out guiding principles to clarify the ideal end state. Basic principles might include:

• The API is the first user interface (UI) for every JTBD.
• Every new product or service starts with the description and design of an API.
• APIs provide a broadly useful universal service or utility. For this reason, APIs are designed to be completely client and channel-agnostic.
• All APIs should work equally well for internal or external consumption. This is because we cannot predict which JTBDs will be performed internally, externally or as a combination of the two.
• The bare-minimum API security requirements are authentication. These are non-negotiable. APIs are holes in your firewall and easy pathways for horizontal traversal. As such, they must be treated with great care and guarded by a Web Application Firewall (WAF) and authenticated at the beginning of each session.
• APIs are defined and documented before they are published. Put the API horse before the cart, always.

Just like the Twelve-Factor App defined the way application developers should write apps for the cloud, your API principles should define how your team writes APIs for your business goals, all while staying in compliance with your technology principles.

Step 2: Visualize the Destination

Start with a vision of what your company will look like in an API-first state. Then, work backward from there. For example, if you are a fashion merchandising company, API-first may mean all content, commerce, and logistics channels are driven by API architectures that feed various consuming front-ends and applications. This flips the standard paradigm of separately developing a mobile app, web app and presence inside different commerce platforms or resellers. On the logistics side, this could mean that all data around shipping materials, sending batches to stores and direct-to-consumer shipping are contained in a singular set of APIs, or even a single API. Start with the end in mind and design backward.

Step 3: Inventory Your Existing API Footprint

Count up all the APIs that your organization publishes, either for internal or external use. Chances are there are more than you realize because teams may be creating them for their own use. These teams could be the best change agents and evangelists for transforming your organization into an API-first company. The inventory will also give you a good idea of what is being done with APIs, how your developers are considering to use them, and which practices and tools they are actively employing. Generally, it is easier to standardize API development around tools that leading-edge developers are already using. Then, you can empower them to evangelize others or become the “practice experts” inside your organization. Platform teams can curate from these toolbelts while gaining a better understanding of how that maps over to the infrastructure and collaboration tools. For NGINX, being a widely deployed web server and load balancer, also has an API Management solution.

Step 4: Determine Infrastructure and Collaboration Requirements

In this step, you’ll need to collaborate with your DevOps and Platform Ops teams to understand how the APIs will be used and which tools they prefer.

Different API types and use cases can have varying requirements related to environments, levels of compute support, and attached storage for transactions.

Sample infrastructure requirements:

• A customer-facing financial transaction API might require a low-tolerance SLA and very low latency, which could dictate that support for that API requires N+3 instances in different data centers around the world to push the API processing closer to the client calls. An API Gateway that’s optimized for high performance may be needed for this scenario.
• APIs that are internal and require only consistency (not low latency) may live happily with less stringent SLA on older, slower hardware and in fewer data centers.
• Because GraphQL is designed to handle many query types and often interacts with a graph database, GraphQL APIs may require more computing power and a bigger communications bandwidth than more narrow REST APIs.

Ensuring a common collaboration environment for the creation of APIs is just as important as the infrastructure support. Postman and SwaggerHub are the leading providers of API collaboration and hosting platforms. Their tools automate a lot of the heavy lifting such as API schema generation and documentation.

Preparing for API-First Design, Creation and Implementation

Once they’ve envisioned and evaluated during the first phase of their API-first journey, API-first organizations prepare to transform their cultures by crafting supporting design principles and infrastructure. The next article in this series will help you make the most of your journey and include the people who are perhaps your most important stakeholders in the creation of this new culture — your creators and developers.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Postman.

Featured image via Pixabay.