Creating an API-First Culture and Company, Part 2
This blog is part of a 4-part series.
- Creating an API-First Culture and Company, Part 1
- Creating an API-First Culture and Company, Part 2 (this post)
- Manage Your APIs Like a Four-Star Restaurant (Part 3)
- How Platform Ops Teams Should Think About API Strategy (Part 4)
In our first article, we showed how organizations can lay the groundwork for an API-first culture. APIs are transforming our technologies, redirecting companies and enabling important technological shifts. API-first companies are well-positioned to be competitive and drive innovation in their industries. As such, how organizations can transition to API-first thinking is a key consideration, even for those who are not API-as-a-Product companies.
Part two of this series continues where we left off, introducing Phase 2 (Design and Create) of the process of creating an API-first culture. How API-first cultures are designed and evaluated sets the standard for how they’ll fare in this third wave of the API economy — where APIs continue to drive a shift away from monolithic infrastructures and toward better technological utilization.
Phase 2 of the API-First Culture Journey brings the enterprise into the design and creation of an API rulebook, design principles and infrastructure. From there, your stakeholders are invited to participate in shaping your new culture and continuing your API-first journey.
Phase 2: Design and Create
Step 5: Create a Set of Design Principles for Your APIs
For an enterprise to truly become API-first, it must have a shared view and set of rules around how to design APIs. Start with general design principles. Two examples include:
- Platform independence: Any client should be able to call an API, no matter how the API is implemented.
- Service independence: The API owner should be able to evolve and add functionality completely independent of any client applications.
Other rules might dictate economy of character use, meaning every character in an API’s URI structure is used and any extraneous characters, such as forward slashes, will break URI calls. A single question should guide the principles: How will the users consume and write against this API? The answer should reasonably be the same for internal and external users. These may sound like basic, common-sense design principles, but it is crucial to lay the foundational expectations and guidelines.
Note: This is also a good time to engage security teams and get their input on design patterns for APIs that will reduce attack surfaces and risks.
Step 6: Create an API Rulebook
Yes, rules are boring — but they’re also necessary. Sloppy API design can create many problems down the road. While developers never set out to design a sloppy API, factors like time pressures or partner requirements can negatively influence design choice. Choose what types of APIs you want your organization to support: REST, GraphQL, gRPC or even SOAP (an older but still useful API structure when dealing with legacy systems). For each type of API you decide to support, lay out a style guide that describes specific design criteria (URI structure, schema, etc.).
Step 7: Set Up API Management and Security Infrastructure
Managing and securing APIs can be done with existing load balancers, reverse proxies, or ADCs; however, it will require additional functionality. APIs are distinct from standard traffic requests due to being machine to machine and exhibiting different consumption patterns. Securing external APIs requires a new mindset because, by default, an external API is punching a hole in a security perimeter to open up a service — similar to web traffic through firewalls. In the case of APIs, there may be numerous ports opening and closing for different purposes and services, each with its own set of expected and permitted business logic. For internal APIs, it’s equally important to set up proper management of performance if you plan to shift business critical functions to those APIs. Traffic flow and management of internal APIs should all be within the corporate network — otherwise you are compromising your security.
Phase 3: Elevate and Educate
Step 8: Create or Elevate a Slate of Lighthouse API Projects
Visible success stories inspire people to dive into API culture and creation. Ideally, these success stories involve innovative new products or touch on core capabilities that the particular business relies on day to day. It is helpful to create a diverse slate that covers external and internal use cases and a range of service types with different requirements.
Alongside this program, set up explicit goals for an expected outgrowth and evolution of your API-first journey. Get buy-in from top executives who are fans of the API economy and are willing to highlight the progress of those at the top. And ensure that the creators and developers — your most important stakeholders — are happy to participate and become API luminaries inside your enterprise.
Step 9: Create API Ambassador and Education Programs
With open source technologies, companies like Comcast and Microsoft have set up ambassador programs that highlight internal experts in different open source areas. These experts are then offered as consultants to other employees who want to contribute code to open source projects. Similar ambassador programs are widely respected and successfully deployed across dozens of companies. API ambassadors can help educate developers who are new to APIs, helping them grasp the process of planning and building APIs.
Another common tactic is to launch an internal API university and series of training sessions. Ideally, these should be focused on real API projects where developers are building something that the organization is actually going to implement in the near future.
Get to the API-First Mindset
Following the above phases and steps will increase your chances of API success. The key is to take a holistic and realistic approach when transitioning your technology and product development over to an API-first mindset and execution framework. Like any technology adoption journey, carrots and encouragement work better than sticks. And similar to any major paradigm shift, you will need to think through addressing the needs of API-facing teams, from developers and DevOps to infrastructure and security teams tasked with locking down APIs. It’s never too late to become an API-first company and reap the benefits of moving to a modular, JTBD approach in creating products and functionality.
The benefits don’t just include increased efficiency and agility — they also involve greater autonomy for developers and small teams, granting each agency to build and fully own something. It’s clear why the tech giants who are native API companies seem to move so quickly and iterate so rapidly; why Amazon can launch dozens of new cloud products each year. The good news is there’s no secret sauce — just smart planning and logical steps to spark your own API transformation.
