How Do You Become an API-First Company?
API-first continues to shift the business landscape, with API-first leaders like Amazon, Stripe, and Twilio shaping how we all do business while also enabling entirely new approaches to doing business that weren’t even conceivable just 25 years ago. Becoming API-first begins with planning and taking small incremental steps to define, standardize, and perpetually optimize how you deliver and operate your applications and integrations using APIs. It’s critical to have a strategy for how you quantify APIs, but also move them forward consistently and reliably across the API lifecycle, redefining your teams and operations with a commitment to evolving your enterprise operations in an API-first world.
In my previous API-first blog posts, I talked about what an API-first company is and why it’s critical today to be API-first. Now, let’s look at how to become an API-first company. When studying the approach of API-first leaders across the global space, we’ve seen some common patterns emerge for how they are running their businesses that stand out from other providers. Let’s take a quick look at these proactive steps to becoming API-first, and then you can work to rebuild your own teams and operations to fit the API-first world.
Always work on your strategy
To be API-first you need to have a plan. You need to draft an overview of what you are looking to achieve with your API operations and begin recording more of the details regarding how you are currently doing this and some of the things you’d like to see improve. Document what your current API strategy looks like, but then begin to develop a road map for your formal API strategy, defining what some of your next steps will be. This allows you to get more organized in how you approach doing APIs and do it in a way that can be easily communicated to others.
Make sure all APIs are discoverable
To be API-first you should have a complete inventory of artifacts used across APIs being designed, developed, and operated in production while working to create artifacts for APIs where they don’t exist. There are four types of artifacts being used to describe the surface area of APIs, which when published to API workspaces and repositories can contribute to the discovery of APIs and microservices across operations.
- OpenAPI: JSON or YAML descriptions of all web APIs and webhooks
- AsyncAPI: JSON or YAML description of event-driven APIs
- JSON Schema: JSON descriptions of the schema objects used for APIs
- Collection: JSON Postman Collections for mocking, documentation, and testing
These machine- and human-readable artifacts are essential for mapping out the API landscape that exists across an enterprise, ensuring that APIs are discoverable as part of searching and browsing of private, partner, and public API catalogs that enable you to quickly find all APIs as part of any other work that is across teams.
Prioritize APIs over applications
To be API-first you should always be prioritizing the planning and development of consistent and reusable APIs before you begin writing any code to deliver web, mobile, and device applications. The prioritization of APIs over applications allows for the digital resources and capabilities being used in applications to be defined early on, making sure you don’t duplicate API resources that already exist, and making sure APIs are designed and delivered in alignment with a wider platform API strategy. An organization will then have greater efficiency, reusability, and quality across all of the APIs behind the applications it depends on.
Be confident with your visibility
To be API-first you will need to have the ability to effectively manage API authorization and access consistently across internal APIs so that they can be quickly made available to partners, or even third-party developers via publicly available APIs. Ensure you have the API gateway, authentication, rate limiting, logging, and other essential capabilities for managing APIs confidently in a zero-trust environment. Your organization’s digital resources and capabilities will always available wherever they are needed, whenever they are needed by your teams.
Realize quality across operations
To be API-first you must have contract and performance tests available for every API and microservice, with tests available for developers to manually run locally and on the web as needed, baked into CI/CD pipelines, or scheduled from multiple regions via monitors. APIs must meet a minimum level of quality no matter what team is developing and supporting them, with machine-readable and verifiable tests across 100% of operations, and results made available via reporting systems and piped into existing API solutions. An API-first company makes API quality a priority across teams and consistent across private, partner, and public APIs.
Consistently apply security
To be API-first you must have security tests in place for every API and microservices. Provide executable security tests that can be manually run by developers locally or on the web, enforced via CI/CD pipelines, and scheduled to run across multiple cloud regions via monitors. Push API security further left in the API lifecycle by equipping developers with standardized ways to make sure their APIs are secure throughout the API lifecycle. Make API security a default part of API operations without requiring that all developers become API security experts.
Increase developer productivity
To be API-first you need to establish well-defined workspaces with the proper visibility for teams to design, develop, and manage APIs within. Each API workspace is in sync with repositories used to deploy and integrate with APIs, going to where developers are already working to deliver and iterate upon APIs. This helps organize API operations across teams into consistent workspaces where team members know they can find the artifacts, documentation, environments, tests, and history for every API across an organization. Team members have what they need, when they need it, across any API being delivered across business domains.
Reach your maximum velocity
The velocity across teams developing APIs will be directly related to how consistent and well-known the API lifecycle is, and how comfortable each team is with moving APIs from design to deployment. To achieve maximum velocity across teams you will need teams to possess the skills and awareness required to deliver high-quality APIs using an agreed-upon lifecycle in a collaborative environment that is equipped with an asynchronous feedback loop. Establish proven and repeatable processes that teams are comfortable with to deliver APIs as part of regular operations.
Increase your API observability
Being API-first requires there to be 100% observability across all APIs, tapping the outputs from across contract, performance, and other types of tests being applied to APIs via CI/CD pipelines and scheduled via monitors, with results available via reporting and existing APM solutions. API-first companies leverage the outputs of Postman Collections used to test APIs to make sure that the health and activity across all APIs are viewable via dashboards and reports. This provides leadership the awareness needed to understand the state of operations and make informed decisions around what to do next.
Platform-led governance across teams
To be API-first you must invest in API design, documentation, testing, and monitoring governance. Allow for more consistency across the design of APIs, but also when it comes to documentation, testing, and how you monitor APIs. Establish a formal design style guide to communicate API governance across teams, but then also enable the automation of governance during design, development, and build time via CI/CD pipelines. This enables a platform-led approach to define, apply, and evolve API governance across API operations, helping make sure APIs—and the operations and teams around them—are more consistent.
Standardize all of your APIs across teams
To be API-first you need to consistently apply common patterns and standards across APIs and teams. Web, industry, and organizational standards should be well-defined and made available to teams for use across their work. It should be easy for teams to learn about and apply common standards when designing, developing, deploying, and managing APIs, beginning with the design of APIs, then also standardizing processes and policies that are used across operations. Educate, but also make examples of standards being applied to APIs so that best practices are demonstrated to teams—setting the bar for how standardized APIs are across a platform.
Be proactive when it comes to regulations
To be API-first you must have discoverability and observability across operations to be able to effectively and efficiently respond to regulatory inquiries, and be proactive in addressing regulatory compliance. All of your data should be available as simple, discoverable, and observable APIs, leaving satisfying regulatory requirements confidently and quickly. Establish a platform-led approach to managing operations in a way that will always be responsive to the regulatory environment that exists within an industry, while also being capable of automating the publishing of regulatory reporting using API provided by regulators.
Always incentivize innovation across your teams
To truly be API-first, you must invest in the optimization and streamlining of your API operations until teams have the freedom to invest in the work that matters. Actively incentivize teams to innovate by optimizing operations around them and carving out a percentage of time that is dedicated to new and interesting products and capabilities. By reducing friction for developers across their work, they’ll have more time to develop creative solutions to problems within a specific domain.
Becoming API-first doesn’t happen overnight
You should be able to begin working on almost all of these areas as part of your regular operations through the prioritization, development, and iteration of a formal API platform and lifecycle strategy. By optimizing and improving how your teams are working today, you will allow them to take the first steps towards moving your operations into an API-first world where you will be able to meet the future needs of your business.
Becoming API-first doesn’t happen overnight with any single task or outcome; it requires a significant amount of planning, collaboration, and communication across an organization. Hopefully this post provides you with some areas you can start focusing on in order to become API-first. Take what you’ve learned here and apply what works for you and your teams, then continue strengthening your investment in moving your organization to be a leader in an API-first world.