API Governance: A Deep Dive From An Enterprise Perspective

If your organization believes in the API-First approach, then APIs become the first-class citizens, and everything that you do as part of the day to day work revolves around them. Your business processes hinge on the availability of some data obtained from APIs. So does the OKRs (Objective and Key Results) of your service delivery procedures, and countless other organizations workflows that move your business forward. This is good news, and it is undoubtedly in line with the industry trends around building an API driven economy. However, adopting this approach requires a well thought-out plan and execution strategy.

API governance is at the core of this planning. An established API governance framework triumphs all ad-hoc measures to boost organizational efficiency. In this blog post, we discuss the importance of API governance for an enterprise. We also cover the strategies and best practices for framing an enterprise-wide API governance framework.  

 

What is API Governance?

The problem of API adoption is that of the problem of abundance. Nowadays, there are many services available via public APIs. Most of them offer a freemium subscription. This makes it easy for employees to try APIs for official purposes, without any organizational oversight. If this situation sounds familiar to you, you have an API governance problem. 

This problem is akin to the initial days of the BYOD (Bring Your Own Device) trend in companies.  Employees started bringing their own devices to their workplace. They started using them for official work, bypassing all organizational policies and protocols for accessing data and apps, thereby putting the company at high risk. This situation necessitates a change in IT governance. 

What Happens Without API Governance?

Depending upon the usage scenarios, API governance has similar ramifications as BYOD. 

If you think of yourself as an API consumer, then here are a few unsavory situations that can evolve in an organizational context:

• Business Analyst Consuming an API:  You are a business analyst. You rely on an API to gather market data to prepare a report. This report holds importance in deciding whether your company wishes to enter a target market or not. Since this is a new business initiative, you want to ensure that the API gets its data from reputed sources. You do a quick Google search and find an API that seems right, and you go ahead with it. Later, when it’s time to present your report and justify the numbers, the API request times out.
• Software Developer Using an API: You are a software developer entrusted with the development of a mobile app for a project. During the development phase, you decide to use an external API to build a specific functionality within the app. The API gives a generous free quota, and so you are enticed. You want to integrate it inside the app to reduce your development effort. Everything works fine during the unit test and integration, and you ship the app with this API. Later, during the production deployment phase, the app goes dead. You realize that the API cannot handle the spike in the number of logged-in users.
• SaaS Provider Using an API: You are the owner of a small SaaS company. Your company sells an app to fishing companies for keeping track of their daily operational workflows. Your app also provides a recommendation system that allows the fishing boat operators to know the weather conditions. It helps them in planning their voyages during the most favorable conditions in the sea. For this, you rely on an external API that provides data about the weather. Everything is going well until one day when the recommendation system starts giving weird information, which is quite a contrast to the actual weather conditions. You are swamped with support calls complaining about this issue, and you do not know what’s going wrong.

What Do You Learn About API Governance From These Situations?

For a start, there is a need for a process to select external APIs. The selection criteria should take into account some crucial tenets. These include parameters such as the credibility of API service providers, the reliability of the API, and the veracity of data provided by API. 

Further, even after vetting the APIs, there is a need to monitor their usage. This responsibility comes under the purview of the API managers. These folks are typically the IT guys responsible for managing the API infrastructure.  

Finally, using many APIs also leads to redundancy. It is about using multiple APIs for the same purpose. Such practices hurt the organization’s productivity. It also impacts the finances and may also lead to unaccounted usage and billing. 

Tackling of all these problems can be synergized into a well-defined process workflow. Coordinating this workflow between the API providers and API consumers is the eventual goal of any API governance platform.

Let’s take a closer look at what it entails to have an API governance platform.   

 

Scope of API Governance

Two essential functions encapsulate the real purpose of API governance:

1. Policy: A policy definition that applies to the entire lifecycle of the API, such that the operations performed on APIs by a user persona during each stage of the API lifecycle, is defined and configured effectively.
2. Enforcement: A mechanism that connects the API providers, API managers/administrators, and API consumers, and facilitates the orchestration between them, under strict enforcement of the policy framework.

There is an intricate linkage between the API lifecycle stage, the personas, and the types of interaction.  Here is an excellent way to summarize it via the API lifecycle stages.

Source: https://dzone.com/articles/the-api-life-cycle  

The above depiction of the API lifecycle varies from organization to organization. However, the core interactions remain the same. 

Additionally, there are also a few one-time activities performed as part of an API’s lifecycle. Activities such as deployment, depreciation, and retirement define the initiation and termination related tasks for the APIs.  These things happen only once.

Essential Features of an API Governance Platform

No matter the size of your organization, if your business relies on data provided by API, or if APIs are deeply ingrained into your organizational workflows, then you must give a hard thought to API governance.

However, governance of APIs is only possible employing a system that manages the APIs, their lifecycle progression, and access control. Typically, all these features are part of an API management platform. API governance is the most crucial part of this platform. Hence, in the context of describing a platform for managing the APIs, both API management and API governance mean almost the same, and both terms are used interchangeably.   

A good API governance platform gives you the power to streamline the adoption of APIs. It makes the APIs seamlessly accessible across different personas within and outside the organization. Above all, it enables you to work within a process that manages the APIs within the organizational policy framework.

If you are considering a platform for API Governance for your organization, then here are the essential features that you must consider:

1. Access Management: Managing access to the APIs is perhaps the most critical consideration in an enterprise set up. After all,  hundreds of employees from different departments are likely to access them. This requires a top-down approach to define roles and permissions for users. Further, different kinds of API interactions also must be configured to enable fine-grained secured access. Access management is also applicable for guarding against unusual and unanticipated surge in access, by throttling and rate-limiting the APIs. 
2. Audit Trail: APIs are also somewhat like resources within the enterprise. Just like ERP systems keep a tab on the utilization of resources, APIs also need to be tracked. A comprehensive audit trail helps the API governance teams to track down malicious usage patterns and handle any anomalies during the API lifecycle.
3. Ingress/Egress Control: It is vital to ensure that only trusted computers access the APIs, and vice-versa. This requires policies for whitelisting the ingress traffic based on IP addressed and/or other parameters. The same also applies to internal APIs accessing external networks.
4. Deployment Options: Deployment options vary based on the combination of cloud and on-premises resource availability. Different deployment options have tradeoffs in terms of cost, availability, and scalability. Based on your budget, you must consider a platform that offers the most flexible option. However, the platform vendor must assure support in migrating to another deployment model in the future, if the need arises.   
5. Analytics: Last but not least, the kind of analytics provided by the API governance platform plays a huge role in the buying decisions. After all, your API governance team will spend the maximum time analyzing the API’s performance and its usage patterns.

 While this list is generally applicable for standard API governance practices, depending upon the size and scale of your enterprise, your expectations from the API governance platform may expand to cover certain other aspects as well. 

As an example, if your organization relies on a lot of internal APIs, then you will consider certain API governance enforcements for launching and hosting the APIs. However, we can argue that the hosting aspects of an API are different from core governance responsibilities because hosting involves the management of the underlying server infrastructure of the API that does not have a direct linkage with the personas interacting with the API during its lifecycle. 

Either way, when you decide to set up a system for API governance, API hosting is automatically a part of it. Depending upon the capabilities of the platform, the responsibilities of governance may extend beyond the typical API lifecycle. Therefore, during your purchase decisions for the API management platform, these aspects must also be taken into consideration.

Building a Strategy for API Governance

It is common knowledge that the problem of governance becomes harder with the increase in the size of the organization. It is applicable for the governance of everything, including human resources, enterprise assets, IT systems, and even APIs. 

It is important to start with an API governance structure that aligns with the basic pattern of the organizational structure and expands to address all touchpoints where employees access the APIs. With this in mind, you can devise a four-part strategy for administering an effective API governance system across your organization.  Briefly, this strategy can be depicted as follows:

This process is closely tied with the capabilities of the API management/governance platform. Therefore, you must pay close attention to the alignment of your needs to the platform features. 

Part 1 – Defining API Access Policies

Everything starts with a plan. In the case of API governance, the plan must address the constituents of an API governance policy that defines the rules for interacting with an API.

A policy must define the accessor and accessee for any kind of API interaction.

Typically the accessor is a user, and the accessee is an API. However, to make a uniform policy definition that applies to a large number of users, you need to bunch them into roles. The roles are further aggregated into teams or departments.     

Similarly, the policy definition must be flexible in addressing the accessed API. Instead of defining separate policies for each APIs, you should have a way to aggregate them.  One of the ways to do this is through the use of tags. 

However, for the policy to be effective, it must also include two additional components.

1. Actions: As we saw earlier, an API is invoked with different types of interactions by different personas during its lifecycle. As part of policy definition, it is essential to include the interactions that are allowed for a user to access an API. Otherwise, it becomes difficult to separate the API management interactions from the API usage interactions, both of which are two distinct operations handled by separate personas.
2. Predicates: In addition to the actions, the policy definition also includes certain predicates, which are the additional criteria for deciding whether a user gains access to the API or not. Some examples of predicates include:
   1. User Properties: Additional properties attached to the user, such as their department names, their designation, or role as per the organizational hierarchy.
   2. API Properties: API properties such as tag, version, and other properties that are attached to each API. 
   3. Date/Time Range: This is a kind of an external predicate that lets you define fine-grained API access control based on certain days or specific times during a day.    

Part 2 – Administering Identity and Access Management 

With the policy framework defined, you now move to the actual deployment of the API management platform.  Once deployed, the first thing to address is the administration of the identities and access management policies.

An identity defines a user. The user accesses the API management platform to interact with the API in one of the ways as defined by a role. Apart from this, multiple users and roles are aggregated into teams. It is also important to note that the API management platform must support a Single Sign-On mechanism to authenticate users that are already registered with the organization’s employee directory.

Additionally, you also define the tags for defining the intent and purpose of the APIs. This is useful for setting policies of accessing APIs and also for making them discoverable based on search keywords.  

At the end of this phase, you should have the users accessing the platform, roles and teams defined, along with the policies and also have a list of tags based on which you want the APIs to be categorized.

Part 3 – Onboarding APIs and Enforcing Access

Now is the time to start using the platform. 

At first, you have to test the system to ensure that it performs as per your policy. For this, you have to follow the instructions as per your API governance platform’s manual, to on-board an API. Additionally, you have to set its properties.

Broadly, there are two things you have to enforce, once you have a few APIs listed and available on the platform. These are visibility and access.

Visibility is about making the APIs discoverable. Your API management platform may offer multiple options to discover APIs based on tags, description text, and other means of aggregating APIs, such as maintaining collections of APIs. You must test the API discoverability based on the permissions given to the logged-in user as per the assigned policy. 

Once the API is discoverable, the user requests access to the API. This is the most crucial test of enforcing access to API based on the assigned policy. This scenario usually applies to the API consumer.  For the API provider, the test must ensure that only the API provider has permission to perform maintenance and upgrade actions.

In the end, you must ensure that all the policies defined in part 1 are working as per their intended enforcement rules that are applicable for all users, roles, teams as well as APIs.

Part 4 – Monitoring API Access and Usage

Monitoring is an ongoing process, and the day to day monitoring of API is part of the general API management chores. But from a governance point of view, there are a few things that you must test to certify the platform for organization-wide deployment. 

• Billing: In case of accessing paid external APIs, you must enforce limits on the billing. The platform must be capable of configuring these limits on a per-user, role, or team basis. 
• Rate Limiting:  To prevent unaccounted usage of the APIs, API management platforms allow the API managers to set limits on the API calls. The platform may allow additional settings to enforce these limits on a per-user or per API basis for a given time. It is a good practice to define these limits in line with the allowed budget for the API billing.   
• Notifications: The API management platform supports notifications for incidents related to billing and rate limits. These notifications are also configurable for a certain percentage of the limit on billing and usage. It is crucial to configure notifications so that API managers/administrators get notified. 

Another thing to consider is the API security governance. APIs may occasionally exhibit high latency, or be unavailable due to particular security-related attacks at the API backend. These events must be captured and made available as a dashboard for a routine quality analysis of the API performance.

Once you have tested the notification for usage and billing limits, your platform is now ready for trial, to be deployed to the broader audience across the organization.      

Best Practices in API Governance

Any form of API governance initiatives requires a cross-functional coordination between the various stakeholders in an enterprise. There are direct as well as indirect stakeholders. They are present across management layers, corporate functions, and department boundaries. In some cases, the partners, suppliers, and customers of the organization also access the APIs. In such cases, APIs are exposed beyond the organizational boundaries as well.

Hence, the adoption of specific best practices is imperative for an effective API governance framework. With emerging API trends and use cases, It also serves the organization well in the long term. The following guidelines should help you adopt these best practices:

• API Governance Process: Any cross-functional governance initiative requires an overarching drive from the stakeholders. Usually, stakeholders cutting across the department boundaries have a difference of opinions. Therefore, the execution of an organizational workflow must happen within a systemic process. Most importantly, it must take into account all checks, regulations, approvals, and exceptional situations. API Governance also requires this kind of a well defined systemic approach. The API governance platform is only a part of this process. It does not supersede the process. Hence, a well defined organizational process must be instituted for API governance. Ad-hoc processes or stop-gap measures do not suffice in this case.     
• API Versioning: API specifications are always subjected to change. The addition of new enhancements and abandonment of older features is the norm of any product, and APIs are no different.  API versioning is the best way to keep track of these changes. Moreover, API versioning is also the basis for managing the lifecycle progression of APIs. It helps in managing the deprecating and retirement of APIs gracefully.   
• Integration with other processes: Management of APIs and the enforcement of governance policies is tied to the other organizational processes. As an example, a user leaving the organization needs to undergo specific processes to relinquish his access to the IT systems. With an integrated Single Sign-On mechanism, the API governance is also part of such change events to prevent users from accessing the APIs. Similarly, there are other change management processes in other organizational functions that impact API governance as well. These cross-functional process dependencies must be well-thought-out as part of the API governance process during the planning phase itself.    
• API Environments: The APIs need to undergo testing before they are suitably employed in a real business environment. Internal APIs must go through a process of testing under a staged environment before moving on to a production environment. Similarly, external APIs must also be evaluated under a trial environment before being moved to the production environment. The API Governance platform must allow multiple environments to coexist to test and evaluate APIs under controlled conditions.     
• API Documentation: Documenting an API in an obvious requirement that does not need any mention. However, from an API governance point of view, certain documentation related practices can ease the burden on the process and enforcement. Firstly, the documentation sections must be templatized to make mandatory and optional sections. In addition to that, documentation updates must be part of the API lifecycle interactions, such that those interactions are made publicly available in the form of searchable logs and discoverable features of the APIs.
  

---

The Rakuten RapidAPI Enterprise Hub is the one-stop solution for enterprises to manage APIs. The Enterprise Hub enables organizations to define a centralized policy and governance framework to access both internally hosted APIs as well as external, third-party APIs.  It comes with comprehensive analytics and monitoring capabilities to keep a track of API consumption along with a rich set of features for API governance at scale.

If your organization needs help in setting up a system to manage third-party APIs, send us an inquiry right now.

---