APIs are a central element of any digital-first organisation. Whether you are a software-as-a-service or enterprise organisation, it is essential to establish and grow a formal API programme. This article outlines three critical steps to help you establish and grow your API efforts.
Step #1: Select the appropriate API governance model
API governance models vary based on the level of centralisation and the degree of control exerted over API design and implementation. API governance models include:
Centralised governance
A single central team or authority is responsible for all aspects of API governance, often as part of an API C4E. This model provides high consistency and control as a central team defines the standards, approves API designs, and enforces compliance. However, it can also slow development and limit flexibility for larger organisations that must depend on a small centralised group to review and approve all APIs.
Federated governance
The responsibilities for API governance are distributed among multiple teams or individuals across the organisation. Teams have more autonomy over their portfolio of APIs but must still adhere to a set of centrally defined standards. This balanced approach offers a bit of centralised management combined with more autonomy.
Distributed governance
A model where each team has complete control over their APIs with no central authority. This model offers maximum flexibility and speed but at the cost of inconsistencies and duplication of effort.
Hybrid governance
Combines elements of centralised and decentralised governance. For instance, a central team might define broad standards and guidelines, but individual teams have discretion over implementing these in their specific context. This approach is helpful when organisations must support business units created from acquisitions still operating independently.
Automated governance
This model leverages automation tools to enforce governance policies. This specialised form of governance combines one of the previous models with automation. Automation is often handled using an API linter.
Select the governance model that best fits the size and structure of your organisation. You should start with one governance model and evolve as your organisation grows.
Step #2: Establish API engagement models
An API programme should focus on more than enforcing the rules outlined in various API governance documents. It also includes multiple engagement models necessary to meet teams where they are today and help them deliver high-quality API designs that meet the needs of end users and API consumers.
Let’s look at a few ways to engage with your API community.
Community support
Quick turnaround engagements through an open community, such as Slack or Teams rooms, available for anyone to join and ask questions. Answers include directing the person to an example of how another team solved a design problem.
Office hours
A weekly recurring office hours meeting is shared with the organisation. The API community can join and bring their questions. Since this format supports screen sharing, teams can share a proposed solution and discuss alternative approaches to their API challenges. It is recommended to keep discussions under 15 minutes to allow other teams to ask their questions.
API design session
A one-hour discussion on a specific team’s API challenge. These may be requested using a form-based approach, such as through a ServiceNow workflow, or scheduled during office hours as time runs out.
API design review
One or more sessions focused on API design review and feedback. Unlike the previous engagement models, this one requires more time. Teams should share their design artefacts, including OpenAPI Specification documents, sequence diagrams, README documentation, and anything else that elaborates on how their API is meant to be used.
API design facilitation
A “white glove” engagement that involves more facilitated design sessions. These engagements demand more dedicated time and are applied to high-profile and high-priority initiatives that benefit from additional hands-on design guidance.
Not all engagement models may be a fit for your organisation. Start simple, select one or two models, and expand your engagement opportunities as your API program grows.
Step #3: Scale your programme through federated API coaching
Once your API governance model is established, and your engagement models are selected, it is time to start thinking about how to scale it across the organisation. Your organisation may only have a small number of developers involved with API delivery, or you may have thousands of developers spread across different lines of business and domain areas.
If you have a larger organisation, scaling your API governance model is essential. We recommend implementing a federated API coaching model alongside governance automation. Federated API coaches support their business units or domain areas, reducing the burden and wait time often associated with a centralised governance model.
These coaches are trained and deployed across the organisation to distribute the review process. API coaches also benefit from their domain area knowledge, providing deeper insight than a centralised group that is less familiar with the domain.
Implementing a federated API coaching programme offers many benefits for your API program:
- Coaches advocate for an API-first mindset by guiding teams in more strategic API designs.
- API design issues are addressed earlier in the delivery process when the cost of change is lower.
- Teams avoid rework by being directed toward API standards, conventions, and guidelines.
- Coaches can combine their understanding of the domain area with API standards.
- Design reviews have a faster turnaround time than waiting for a central group of reviewers.
- Institutional memory is better preserved for the domain as API coaches and delivery teams are aligned in understanding the problem and solution.
It may be helpful to scale your API programme by establishing an API coach programme. This may involve a federated API coach model for larger organisations, while smaller organisations can have two or three API coaches as part of a centralised governance model.
