API Governance pt.4: API Governance deployment models

API Governance isn't a singular process, tool, or the domain of a specific group; it's dispersed due to the broad implications involved in planning and operating an API. For instance, a developer may handle ensuring the API meets validation requirements during design and development, while Security and Operations groups take charge of governing runtime behavior in the face of cyber-attacks, be they real or simulated.

However, the crucial aspect lies in structuring decision-making authority to align with our definition of API Governance. As expected, this alignment can be achieved through one of three well-known frameworks – a CoE (Center of Excellent), federated CoEs, or a hybrid of the two.

In lieu of reinventing definitions, we borrow from Gartner: Gartner defines a CoE as a physical or virtual center of knowledge concentrating existing expertise and resources in a discipline or capability to attain and sustain world-class performance and value.

In a CoE deployment model, a centralized body takes charge of generating and possessing the knowledge essential for establishing and operating API Governance. This implies that the central entity bears the responsibility and accountability for crafting compliance policies, rule requirements, reporting necessities, and, optionally, acquiring and managing related software. The CoE effectively becomes the primary point of contact for those obligated to comply. Processes are designed to channel specific decisions through the central API Governance team. In more intensive scenarios, the API Governance team might function as a factory with the explicit purpose of constructing compliant APIs on behalf of API producers. In less extreme cases, the API Governance team delivers essential training, conducts API reviews, and provides feedback. The CoE model is often seen as a bottleneck to scaling.

In a federated CoE model, API Governance hinges on enabling success within the organization through federated teams and non-centralized knowledge management. This push-model establishes a framework by which things can be developed in a distributed way rather than engaging in and driving the development centrally. Federated CoEs are designed to be independent with the focus on retaining agility autonomy and control over decisions that power the agenda of the organizational unit that it’s relevant to. Any notion of a central API Governance body is limited to empowering the federations with know-how and facilitating tailoring of API Governance to the federation’s unique requirements while remaining compliant at an enterprise level. The federation can further self-describe their own governance requirements and how compliance will be achieved. This model works well in organizations that have highly distributed LoBs with independent control over their business and technology strategy.

The hybrid CoE model, in contrast to the others, is a balance of power and decision-making that creates win-win situations for both a central API Governance entity as well as group of business units executing governance in federated mode. Most API governance implementations resemble this model as it is easier to achieve and presents higher degree of flexibility and agility.