As referenced in Part 1 of our series on API and Artificial Intelligence (AI) governance, this blog post examines how your organization's approach to its people and organizational structure may need to change to support the AI revolution. I cover what the industry has learned and done well in relation to this topic, and what won't work for a new AI paradigm.
What We Got Right
When it comes to API governance, the industry is adept at the following aspects and should continue to expand upon them to support AI adoption and scale:
- Federated API Management: Decentralized API ownership and development empowered teams to move faster while a common platform ensured security and reliability.
- Standardized Central Platform: Platform-level capabilities like authentication, traffic control, and policy enforcement allowed teams to innovate without compromising compliance.
- Inner Source for Shared Components: Encouraging reuse through shared libraries and standards drove velocity without reinventing the wheel. An Inner Source structure and approach help clear features delivery bottlenecks and promotes community-driven solutions.
What Won't Work for AI
These are some practices, while prevalent in many API programs, they are increasingly inadequate in the AI era:
- API C4E Without Authority: Community-driven API guilds helped with knowledge sharing but lacked enforcement power. Modern API programs need the reach of a developer guild to drive adoption and innovation, but also its teeth to enforce standards. With the right balance, the governance process would look like an attestation of good community practices, with high rate of successful approval hit/miss ratio.
- Optional Governance: In an agentic world, opt-in governance models leave gaps in compliance, reliability, and security. Given the dynamic nature of workflows in this new paradigm, measurable oversight must be a required "property" of API components, and must be embedded into the organizational DNA.
- Sideline-only Oversight Models: AI programs need real-time, responsive governance—this requires expanding API Centers for Enablement (C4Es) into centers of enforcement and oversight, aligning federated execution with centralized control. As highlighted in the 2021 State of DevOps Report: "The most highly evolved firms benefit from top-down enablement of bottom-up transformation."
To meet this challenge, the API Center for Enablement (C4E) must evolve into a more proactive and platform-embedded approach, providing oversight that is multidisciplinary, policy-driven, and deeply integrated with product and platform teams, not from the sideline.
Note the two types of working groups: Focus Groups for enablement and value creation, and Control Gates for enforcement and value protection. The Oversight Group sits in between to report on both arms with proper oversight metrics.
Figure 1: API Center for Enablement (C4E) as a centralized function, inner-source-type structure.
How API Center for Enablement (C4E) works with other Governance Bodies
The Architecture, Cybersecurity, AI, and any other Governance bodies leverage the API C4E as a Subject Matter Expert (SME) Engagement area. A centralized API management function provides a SME Engagement area, to be triggered for API related initiatives.
API C4E provides a layer of governance and strategic oversight that complements other governance processes. It also provides a layer of protection for the day-to-day development practices, at initiative-level as well as individual component-level, adding oversight to the DevOps pipeline specifically for API considerations.
Figure 2: The needed governance structure for API governance
The needed governance structure is to provide:
- SME Engagement Area representing API Domain for initiative-level reviews.
- Enablement and vetting channel for community-driven solutions
- Component-level reviews and pipeline automation
