API Governance, a Simple Complexity

API Management projects are straightforward. It's all about exchanging data from system A to system B. But that's without taking into account the fact that an API Management project involves a large number of players, which creates complexity.

The Actors Involved in API Management

To begin with, we can list the typical players involved:

• The CxO who has decided that APIs are part of the company's strategy, but who doesn't give you very strong sponsorship;
• The other CxOs who have other priorities than APIs;
• Team A, which wants access to data, but doesn't have the time to deal with you;
• Team B, which is responsible for exposed data, but doesn't have time for you;
• Solution developers who want access to data;
• Solution developers who expose the data;
• Members of the API management team;
• And at least one architect, of course!

As you can see, there's a multiplicity of players, all pushing in their direction. And you quickly lose any form of coordination if :

• The API management team doesn't play a constructive coordinating role;
• There is no sponsorship from CxO members.

The Challenge of Complexity

It is therefore necessary to master the complexity of the company and the complexity arising from its interactions and players. Indeed, according to the theory of complex systems, the complexity of the "company" system lies in the high number of players and the high number of interactions between them!

What's complex is not making an API with one actor, but making an API with, by and for multiple actors.

It is therefore essential to :

• Seek to align all actors in the same direction through excellent communication, explanations of best practices, etc. ;
• Make the API management team a central point of exchange for any conversation about APIs;
• Infuse knowledge into all teams as much as possible.

From this, we can deduce two prerequisites:

• Clear, simple and effective governance is essential;
• Solid sponsorship must guarantee the company's alignment with an API project.

The organization mode most often used is the governance mode I call “open source”. The API team supervises, guides, helps and supports, but above all enables everyone to contribute easily and effectively.

From these activities and challenges, we can deduce two types of activity.

Two Types of API Team Activity

We can divide the activities of an API team into two types of activity: governing activities and extended activities. Indeed, the governance of an API management team must set a framework within which all the players involved in the API must operate, so that all the players can work to their full potential.

Regalian Activities

We can refer to activities for which the API management team has full authority and cannot be removed as regalian activities. These activities include : 

• Implementation and technical administration of the API Management platform,
• Definition of API management best practices,
• API definition workshop formats - to move from endless, counter-productive meetings to efficient, productive ones. I've personally reduced the number of workshops by a factor of 4, just by rethinking the way we run them!
• The organization of API workshops - To be the driving force behind API topics, but free for the API Management team to let the teams concerned organize themselves if they are sufficiently autonomous,
• Managing training and communication - To ensure team buy-in, and to demonstrate the added value of the API Management teams.

Extended Activities

Certain activities, however, need to be carried out not in a purely regalian mode, but on a much more collaborative model - after all, it's all about organizing exchanges between at least two systems:

• Define and manage the API lifecycle with projects and functional architects - Even if the API team has the last word, it remains at the service of the projects and the business! Never forget that!
• Work with architects on the alignment of API needs in a clear roadmap - Architects are supposed to have a medium- and long-term vision of future needs, and API teams are supposed to align with them!
• Tool developers to provide the right tools and frameworks - Telling a project to "go ahead and do the API" isn't enough!
• Contribute to ideation with the business to come up with new API ideas - the aim being to extract maximum value from the company's assets.

2 Governance Typologies, or Rather 2 Governance “Cursors”

Enumerating a list of tasks is not the same thing as defining API governance.

Of these two types of activity, we note that the "decentralized" pattern inevitably comes up.

The "decentralized" mode of governance comes up very often. In this mode of governance, the API Management team's main aim is to enable everyone to contribute easily and efficiently. It's up to the API Management team to frame, guide, help and provide support, but not necessarily to implement and define APIs. It's a governance logic that seeks above all to enable other teams to work autonomously.

In the opposite logic, the other mode of governance we regularly encounter is centralized governance. In this case, API's competence centre brings together all the necessary skills and works self-sufficiently.

However, very few companies have set up a form of governance so "marked" by one of these two logics. It's a question of adapting to the organization of the company and its IT, but also of adapting to the maturity and autonomy of the teams in place. However, you need to make sure that your teams are empowered, otherwise, it will be impossible to "scale" your organization around APIs, not to mention the side-effects of an ivory-tower logic...