API Governance: Three Foundations and the Last Hidden Gem

The Three Foundations of API Governance

At a first glance, one might frown upon the term ‘API governance’ and associate it with negative connotations. However, a platform without a governance strategy can lead to unwanted consequences, such as security vulnerabilities, duplicated services, as well as integration and administrative overhead.

In our experience, API governance’s best practices come down to three core foundations: API ownership, API policy, and API standards. Here is how we brought them into practice:

API-first begins with ownership

As an expat myself, identity registration is not a foreign concept. Without proper identification, a country cannot keep track of its demography, and neither can an API management platform derive any insightful indicators to act on.

Under the API-first principle, we enforce API ownership. Even before any code is written, an API should be given a unique identifier in our central IT asset management system (CMDB). This registry holds teams accountable in managing the life cycle of their APIs from its birth until retirement like any fully-fledged product.

The ownership registry provides the single source of truth for our centralized integration catalogue, one that enables API reusability and developer experience. It also maps out a holistic service overview on the ever-changing API landscape where we as a platform can derive metrics and actionable insights for our decision making.

Embed API policy through OAS and automation

After the identity is established, an expat’s integration journey to a foreign society has just begun. She might want to learn a few greeting words in the foreign tongue and avoid some cultural taboos to kickstart a new trajectory.

Similar to acquiring a new language skill, we mandate the Open API Specification (OAS) to be the common tongue spoken between API provider and consumer. Through process redesign and automation, we deployed a series of guardrail validations against the OAS file of each API. This is to ensure that APIs and the platform adhere to the desired state of security and compliance. In combination with deviation use case management, it guarantees the security of APIs is built in from the start, and allows us to monitor or even avoid non-compliant use cases from the get-go.

An OAS file not only serves as an agreement between API provider and consumer, but also paves the path for future enhancement such as contract testing, which is slowing gaining popularity.

Engage your community for living API standards

A couple of months pass by. An expat has settled in. However, without a community, she is still detached from the local society. A community allows one to socialize, exchange knowledge, help one another, and shape common values towards a newly formed identity. An identity that drives behaviours and defines how one interacts with the others.

While centralized expertise could be a forerunner, we believe that API standards eventually belong to the API community. Standards can be facilitated and encouraged, but without feedback and adoption from the community, they will end up obsolete.

API standards, which consist of best practices and latest design guidelines, promote quality, consistency, and aligned way of working. They foster easier adaptation and reusability of APIs, so the whole organization can reap the benefits of cost-efficiency and faster time to market.

A set of mature API standards is a signal of a strong API management program. It is one of the trickiest foundations amongst the three, especially when it ties together with community management. In my opinion, it requires expertise, diligence and sometimes art.

The Hidden Gem: how engaged is your community?

At Rabobank, the deliberately chosen federated API management approach has made a central team, one that usually reviews and approves each internal API before its release, redundant. Decision making on when, how, and where to manage APIs has been empowered at the squad level to enable autonomy (or to be more specific, “aligned autonomy” as we like to call it).

This approach has driven our decisions from all levels in making our governance model lightweight, automated, self-service, and relevant to the community.

Amongst the API governance best practices in the market, I rarely found the people aspect, or the art of community management brought to the centre of discussion. Yet the people aspect, whether it’s the community or our business stakeholders, together form one of the key driving factors that could determine the success or failure of API governance.

We often put our focus on processes and technology, as if the people interacting with these practices are taking a secondary stance. But when it comes to API governance, where the community plays a vital role, I believe the reflection on whether we have sufficient presence and tactics towards community management is crucial. If our vision is to have an empowering governance model, the engagement of the community might be one of our underlying indicators of success.

Perhaps, this people aspect has not yet received the deserved attention, and we are all still learning to master this difficult craft.

The tango between autonomy and control

How to keep a balance between an encompassing governance model to stay in control, while remaining flexible in responding to the community’s need and mature with it, that is the perpetual quest of our API management platform.

I hope by sharing our practices, the three API governance foundations, and the last important yet often overlooked people aspect, it sheds some light on this topic for those who are also on the same journey towards a thriving API ecosystem, one that lives out the potential of an API economy that we aim to see.