Governance in API Practice

One of the challenges an API Practise team faces in an Organization is Governance.

The aim of Governance should be to make it easy for people to do things the right way and hard for people to do things the wrong way. 

The challenge for API Practise is to have a flexible Governance model that incorporates the 3 Vs (Visibility, Veracity and Velocity).

Governance around API initiative is very much influenced by 

1) Business Patterns (B2B, B2C, E2E etc)

2) API Patterns (Reusable, Non Reusable, Public, Private, Partner, Hybrid)

3) Security Patterns

4) Development/Deployment/Testing Patterns(IC/CD, Integrated testing, Integrated Penetration Tests)

5) Technology patters (CallBacks/Message Brokers/API Gateways etc)

6) Documentation/Publishing Patterns (how /what to publish)

So how would you go about developing a flexible yet robust API Practise Governance around service exposures through APIs? What would be the starting point?

The below mentioned steps offer a foundation on which a more detailed and exhaustive governance could be built. 

Step 1) Identify the Business Patterns:

Start with identifying the Business patterns that your services cater to .It could be B2B , B2C, C2C, E2E ... for example, typically traffic volume for B2B is much higher than the traffic volume for B2C but B2C require more contextual awareness than that for B2B.

Step 2) Build the Security Requirements/Patterns:

Define security requirements/patterns for the above patterns .For example, for B2B use cases we may use OAuth with client credentials as an authorization mechanism but for B2C use cases we may require an "Auth" flow type of OAuth (or any other mechanism like SSO, OpenId etc)

Step 3) Identify Technology Patterns that fits the Business and Security requirements:

Identify and define various Technology Patterns that would be used within the above business patterns.For example, for a B2B scenario would you want to use a combination of micro services and enterprise legacy systems to expose the service? Would you want to have an additional layer of API Gateway for exposure? Would these technology patterns fit into the Security Patterns defined in the previous steps?

Step 4) "Templatize" and Automate where ever possible:

"Templatize" the Development /Build /Testing of the Technology patterns by creating tools and templates for each of them.

Step 5) Setup check points at various stages to accommodate "course correction":

In the above steps one must aim at enabling "self-service". Each of the above steps should produce certain reusable artifacts.

The aspects that are to be addressed in the governance model would vary based on the targeted consumer of the API initiative. For example, less governance is required for internal developers (being part of the same company) compared to partners or public API initiatives. As these internal API initiatives start to work their way outwards, the additional governance considerations need to be added to the early governance implementation.

This is not intended to be an exhaustive discussion on API Governance, however the idea is to show the key areas of focus.

I’d be interested in your thoughts, suggestions and would be happy to discuss this further.