Now that we have the API, operational, people, landscape we can properly inform what API governance should be. The engineering and business platform should define what resources are available for teams to use across internal, 1st-party, or 3rd-party APIs. This is where we define the actual API policies that align API governance with business and the individual machine-readable API rules that will lint and enforce API governance at design, develop, or build time.
- API Policies - Rules and guidance for governing individual APIs.
- Operational Policies - Rules and guidance for operational APIs.
- Lifecycle Policies - What order do APIs get delivered into production.
- Strategies - What are the overarching enterprise goals aligning APIs.
- Stakeholders - Who are the domain experts that are part of discussion.
Now we are getting closer to answering the original question of where do I begin with API governance, but done in a more informed way. API governance is a sprawling and moving target, and without a proper understanding of the API, operational, and people landscape you are likely to lose your way. API governance should always be mapped to a specific part of a schema defining the technical details of an API or the business details of API operations, with the lifecycle moving things forward, strategies aligning with the enterprise, and stakeholders keeping an eye on the direction of API policies shaping everything.
