How to Start Platform-Led API Governance and Overcome Resistance
API governance will always require some form of centralization to be successful, though it will vary between organizations and domains. Governance can be top-down or bottom-up but will ultimately require a balance between a centralized strategy and a more federated approach across the enterprise.
There will always be some resistance to winning adoption, buy-in, contribution, and participation from teams. You just have to be honest about what resistance looks like and be committed to winning hearts and minds through enablement and investment, as well as the occasional enforcement of governance. A certain level of participation across all teams is required to realize API governance, so it pays to have a ready-to-go toolbox for addressing resistance.
Related: Enterprise best practices: successfully govern your API content and users
Sensible centralization of governance
A common and effective way to instill API governance is top-down. This is initiated by technology leadership, defined by senior architects, and championed by energetic and diplomatic individuals who come from the teams or enjoy a deep relationship with them. A group should ideally be formed that reports to the CTO, CIO, and CDO leadership. It should lobby for regular time and resources as part of a platform-led API governance effort.
Leadership buy-in and prioritization will be essential to the longevity and effectiveness of API governance. However, a top-down centralized approach will only get you so far. You’ll also need to invest in bottom-up strategies that look a little more like enablement at the lower levels of an organization.
Balancing with a federated approach
For API governance to achieve saturation across teams, there must also be a bottom-up and federated approach to defining, applying, and iterating API governance. This includes feedback loops and team contributions to what governance ultimately becomes.
Blueprints for definitions, design, documentation, testing, and monitoring will have to be owned at the team level. The vocabulary of governance will have to come partly from teams, as will the application, reporting, and ongoing feedback loop needed to realize API governance widely.
Forward motion has to be at the team level, or you just won’t see the buy-in and coverage needed. The success of API governance and the amount of resistance encountered across teams will be a direct reflection of the balance between a centralized and federated approach.
Keeping teams on track with guidance
Guidance on API governance should be published centrally, but then made portable, hands-on, and automated. Teams can then apply it at the moment they encounter common situations the governance is looking to address. Guidance should be maintained as living collaborative documentation approved by leadership, but actively defined, iterated upon, and proven by those who are delivering APIs on the ground floor.
Governance on the ground is just enablement
Governance on the ground floor of operations should look more like API enablement than governance. Governance is the lens through which leadership will be viewing this, but across teams it must look more like enablement or you will assuredly encounter resistance and pushback at every turn.
API governance should automate the application of API governance rules as part of the design, development, or build process. This turns each broken rule and warning into a teachable moment to help teams understand why the governance exists in the first place.
API governance should go to where developers are, living in the clients, IDE, and CLI where they are already getting their work done. Ideally, governance shouldn’t create more work for teams. It should just enable and augment teams or even automate some of the more common and mundane tasks.
It’s important that teams have the resources to succeed when it comes to API governance, and the process and tooling around their work are as collaborative and observable as possible. In this way, teams are never left alone to navigate the design, delivery, and management of their APIs and microservices.
Meaningful participation across stakeholders
API governance should tap into existing feedback loops that exist with consumers to ensure that governance isn’t just seeing alignment from the top-down and bottom-up in an organization, but also seeing outside-in participation by API consumers. Ensure that API governance is in alignment with business objectives; otherwise, there is bound to be resistance from teams working to stay on track when it comes to meeting their own KPIs and OKRs.
Ultimately the amount of resistance encountered as part of API governance across the enterprise will be defined by business incentives, as well as the incentives associated with definition, design, documentation, testing, and monitoring governance. You’ll encounter resistance from teams until they begin to see API governance as something that helps them and isn’t just more work being thrown on their plate.
Opportunities through design reviews
Through the implementation of regular API design reviews as part of the development, delivery, and maintenance of APIs and microservices, there is an opportunity to efficiently process the API contracts under development. This means opening a window to provide feedback to improve upon and evolve the overall API governance effort, while also educating and developing internal capacity.
Using API design reviews to inject API governance into the ongoing software development and API lifecycle can be effective. When done in a constructive manner, this can produce much higher quality APIs that are compliant with governance while educating teams about best practices for API governance.
Mining value from across discussions
Developers are already communicating via email, Slack, Teams, GitHub, and other channels. These channels have APIs and provide an opportunity to power portions of the API governance feedback loop, helping influence the direction that governance takes.
These feedback loops are also becoming more closely aligned with artifacts driving the API lifecycle, occurring as part of the design and iteration of OpenAPI, AsyncAPI, JSON Schema, as well as Postman collections as they are used for documentation, mocking, and testing of APIs.
When you have these artifact-driven discussions occurring asynchronously within API workspaces organized by business domain, you end up with an effective feedback loop across APIs.
Always be strengthening the champions
The feedback loop around API governance becomes an effective business flywheel only when there are champions involved from across all levels of operations. Feedback loops need to have established flow into leadership and at the architectural levels, informing the overall strategy but also engaging at the team and business levels to enure all stakeholders in the API lifecycle have a voice in those discussions.
By continuously nurturing the next generation of API governance champions, you load-balance what is needed to move forward on API governance while also acknowledging that the churn of experienced talent will always be a factor.
The iterative API governance journey
API governance is an iterative process, requiring the development of guidance and rules to provide the relevant constraints across domains, then iterating upon what governance is and how it is applied by champions across all levels, teams, and domains.
A platform-led API governance strategy emphasizes an artifact-guided and feedback loop-driven approach to ensure that API operations are well defined. API governance requires observability across definition, design, documentation, testing, and monitoring but must also have human feedback loops that exist across domains and the API lifecycle.
API governance provides us with the awareness and reporting we need to understand the health and state of a platform. It allows us to plan, respond, and iterate on the API resources and capabilities needed to do business. It gives us an understanding of the state of our complex enterprise organization as well as the knobs and dials to move things forward and make the changes we need.
What do you think about this topic? Tell us in a comment below.