API governance is ultimately a battle of two polar opposites. On the one side, you have decentralized control, granting flexibility and ease of development for developer teams large and small. On the other hand, you have standardized guidelines and policies, allowing for more secure and compliant development. Governance is a balance between these two extremes, and, more often than not, the victory of one side over the other is a chief source of friction.

That being said, some organizations have blazed new trails in the area of API governance. Today, we’re going to look at six examples of organizations that enacted API governance and got it right!

Atlassian

Atlassian is a giant organization with a large portfolio of products. That’s why the issue of siloed teams was so impactful to their development process. Atlassian often saw internal development breaking APIs or developing without standards, which ultimately increased inconsistency and technical debt.

To resolve this issue, Atlassian decided to tackle API governance by creating a structured framework called Extensibility Standards. This body of standards provides a clear, documented guideline for API design and development, which can be easily shared and referenced.

With the standards document on a Bitbucket instance, automated checks are run utilizing the Spectral toolset to measure compliance. This then generates reporting into locations like Confluence so that teams can be alerted to their state of compliance and the particular areas of non-compliance that need further review.

This process focuses on a bottom-up adoption approach, wherein developers are given tooling and systems to iterate standards. Instead of rigidly enforcing the rules, reporting allows for a culture of transparency and awareness, which can be leveraged to align standards. Though still in progress and at an early stage, these efforts have already seen reductions in errors and broken APIs across the board, as well as fostered a culture of collaborative building between teams.

Vodafone

Vodafone is a great example of pairing standards with frameworks to ensure effective API governance. As a large telecom company, Vodafone needed a solution that was aligned with its business and technology practices, some of which are very different from those of other technology companies.

To standardize their API governance and development, Vodafone adopted the TMF Open Digital Architecture or TMF ODA. The TMF ODA is a collection of standardized APIs that can be used to align further API development, leveraging open solutions for the bulk of their tech stack. According to Vodafone, their mix is made up of 70% open APIs and 30% custom-development APIs.

By leveraging open APIs, Vodafone can deploy a highly modular and flexible architecture for its internal systems while aligning against best practices and standards for its custom development.

The open standards at the core of TMF ODA allow for much higher interoperability, ensuring that systems work together effectively, and the continual alignment of their codebases with the TMF ODA standards makes sure that any API that is compliant internally will be compliant with external TMF ODA-compliant partner APIs. This has allowed for massive industry-wide alignment across standards, including 5G network capabilities and digital asset and service delivery.

Facebook

Facebook’s methodology is an interesting case, as it enforces API governance through the establishment of standards by the nature of each API. In other words, each API is structured within its own confines and governance policies and with respect to one another. This so-called “governance arrangement” allows APIs to operate with each other by respecting the governance of the collective system.

In a paper called “API Governance: The Case of Facebook’s Evolution” by Fernando N. van der Vlist, Anne Helmond, Marcus Burkhardt, and Tatjana Seitz, this agreement defined “the governance of and by Facebook through its APIs.”

This governance takes place across three core levels: the architecture level, the object level, and the permissions level:

• Architecture level: By governing changes to the core Facebook APIs, those APIs can then be used to enforce actions and structures in other APIs through their prominence and influence.
• Object level: At the object level, users are represented through constrained valuations of what is a user, what data that user contains, and how the user can be acted upon, placing further governance constraints on APIs which interact with this object.
• Permission level: Granular access controls placed on top of the APIs in question control how each API can interact with elements of the overall system, thereby governing more directly the API interactions at scale.

The sum total of these efforts has resulted in a de facto governance standard rather than a stated one due to the influence of the core Facebook API set, creating a reality in which APIs can only interact in one way with the Facebook API, which is compliant to the Facebook governance standards.

Mobile/Landline Operator with Tony Harris

Tony Harris documented perhaps the most direct governance strategy in a case study in their knowledgebase. This is a classic case of top-down management with a production twist.

In essence, a large telecom operator in the UK decided to leverage APIs as a methodology to interact with partners and businesses. As they had yet to create their core offerings, this client was in a great position to make a top-down plan. As such, they immediately created an API Governance Team with Tony Harris to create the guidelines, standards, and API development roadmap to reach their goal.

With the framework in place, an API Farm team was created to generate APIs utilizing what Tony Harris calls a “Factory Model.” This team was able to create, develop, test, and deploy APIs in rapid succession based on the guidelines, standards, and feedback from the API Governance Team.

The API Factory team ultimately delivered more than fifty APIs within six months, a success that resulted in the overall governance and development structure being expanded as a core digital transformation strategy.

Microsoft

Microsoft’s solution to the problem of API governance. This API is a unified approach toward software development that uses a single API to connect to various services and APIs for novel development. By defining a universal API with strong governance, the thought is that this API will then influence and standardize the APIs that interact with it, thereby influencing the APIs that then interact with those services. This strong governance through soft power allows the Graph API to have a high degree of standardization even without direct involvement.

This becomes more specifically a governance-focused process in the second piece. To speed up the process of API governance, Microsoft looked to AI — specifically, retrieval augmented generation (RAG). By establishing governance rulesets and training an internal RAG AI on this governance, time for governance review and compliance assurance was reduced by at least 20%.

By augmenting the process of documentation, governance generation, and soft power with RAG tooling, Microsoft can quickly iterate on APIs internally without resulting in a dramatic bottleneck in development or approval.

Netflix

Netflix leverages a novel solution for its API governance in the form of a federated GraphQL platform. The issue is simple — developers needed the flexibility of decoupled and non-standard services, but the UI developers preferred a single unified API for development.

The way Netflix chose to take this on is to leverage GraphQL as a top federated layer upon which resources are themselves made federated. When a movie as a resource is standardized in this way, the APIs that interact with it are governed by the nature of the resource. Although standards and best practices do exist, this federated layer does most of the heavy lifting for governance.

This approach leverages three core components:

• The Domain Graph Service (DGS): A GraphQL service that allows developers to define their own federated GraphQL schema for API development.
• The Schema Registry: A registry of all schemas and changes to those schemas for every DGS. It exposes schemas as CRUD APIs, which can then be integrated and used throughout the development process.
• The GraphQL Gateway: A gateway that serves as the query ingest point from the consumer to the DGS collection.

This approach allows Netflix developers to have a decentralized approach to development, iterating based upon the need of the service rather than demands from the top down. At the same time, this allows for a centralization of standards through the GraphQL layer, allowing for functionality that is decentralized yet standardized for the end consumer.

API Governance Strategies

These are some of the most effective and interesting ways API governance has been done right in the corporate world. As governance is a principal focus for many security engineers and developers, having a bevy of solutions to the complex balance of decentralized development and centralized control is extremely important and will continue to be a source of interest and innovation.

What do you think of these strategies? Let us know in the comments below!