.
API governance means setting up and enforcing the standards for security, compliance, style, metadata, lifecycle, taxonomy, and versioning. In today's fast-paced environment that requires quick decision-making and implementation, having to create standards and complying with those on a daily basis is seen as detrimental. Some projects drag on for years because of never-ending checks and balances as well as the inability to respond in an agile manner to market conditions. However, on the other extreme, not having the appropriate rules around governance may lead to siloed projects that lack adoption and may be vulnerable to costly security threats.
In order to find the balance between the two extremes, it is important to set organic API governance rules; they should adapt to the technology you are using whatever they may be, they should be integrated into the tools you use for API management, and they should be automated to alert and direct as early in the process as possible. The goal is to increase productivity without impeding speed and innovation.
With new market trends, prominent security threats, and emerging technologies, the challenges that those who are responsible for API governance have to tackle change. Now, let's take a look at the current governance challenges and suggestions on how to approach these challenges.
1. Diversified API management landscape
Today, organizations have complex requirements from their API management tools. They have several constraints that they have to work with at the same time; the locations of their customers, the capabilities required from different business units, local compliance requirements, existing team talents, and acquisitions, to name a few. It is virtually impossible to find a single tool to satisfy all these constraints, that's why organizations today have to work with multiple API management solutions distributed among multiple cloud vendors.
In this complex API management landscape, API governance should create and enforce standards while supporting diversity. A single place to catalog and govern APIs proxied by gateways from different vendors, deployed in different clouds, and consist of different microservices would enable visibility and ease of control. This single place would be a directory of deployed APIs and proxied wherever along with microservices in your service mesh. At the same time, it would standardize their metadata (including naming conventions, owners, attached documents, supporting teams), policies, and versioning. It can serve as a single source of truth and shift governance to left by providing tools, dashboards, and communication mechanisms for API product managers, architects, and ops professionals.
2. Proliferation of APIs
API adoption has turned into a standard way of business for different business units to cohesively work, to connect with partners, and to outsource some capabilities to third party vendors for time and energy savings. Having APIs to complete various tasks simplifies interoperability and makes application development faster. However, this way of business has created a situation commonly referred to as proliferation of APIs: there are just too many APIs an organization relies on, and it is hard to keep track of all those APIs and make sure that they are secure.
This is where governance is especially needed. Having controls over all stages of the API lifecycle, starting from design to retirement, approval workflows, and notifications would make sure that the APIs pass through quality checks. These checks would ensure that organizational conventions on naming, metadata, and supplementary documents are satisfied. Similarly, having global security policies applied to all APIs, or a qualified subset, ensures that an API doesn't go to production without the necessary protection.
Even though adding these checks to the process may look like it is creating bureaucracy and making things slow, it doesn't have to. The right API management tools makes these steps integrated into daily ops and automates the process. An added benefit would be an API Marketplace solution that catalogs all APIs, whether built-in house or third-party, with comprehensive supplementary information which increases productivity by making it easier to find and use the right API regardless of its provider. It can also introduce isolation between teams with different responsibilities, publish actionable events and notifications on changes, and even control visibility of APIs at their different custom lifecycle states.
3. Increasing number of API formats
REST, SOAP, OData, Websocket, GraphQL, events, messaging...The requirements of organizations from application-to-application communications are infinite. Therefore, there is an increasing number of types of APIs that respond to different use cases. However, there are still a number of basic requirements that are common across all these types. A governance program should treat all of these API formats and even other arbitrary services and assets as first-class citizens and be capable of enforcing the same rules and policies. These include versioning, style, metadata, approval workflows, notifications on lifecycle changes, and common basic security policies.
In addition to the compliance requirements, a developer portal solution can also provide governance capabilities. It can allow cataloging different API types and also events, assets, and applications with mandatory and supplementary metadata and documentation for developers to easily find and use. In addition to common metadata fields across different types, it can also be customized to include type-specific presentations to increase the productivity of application developers.
4. Custom API journeys
Each organization has a custom API journey depending on their unique CI/CD processes; different tools they use for development, testing, monitoring, and other steps; and the technical skills team members have (everything-as-code, low-code, no-code). Based on their circumstances, an organization's API program consists of many tools connecting with each other. However, governance must be applied at every step of the API journey. To name a few requirements, there may be style guidelines during design, different test cases during development, runtime policy rules during production, and dependency and relationship considerations during updates and retirement.
Even though a comprehensive API governance solution may provide templates to cater to many generic use cases, there may still be many custom requirements. In order to satisfy these requirements, custom code and integrations may be required. That's why it would be good to design the API governance program extensible. Administration APIs, custom extensions, and configurable approval workflows would supplement your governance solution to plug in other tools.
