The API governance survival guide

tyk-blog-LEAP-API governance vs developer autonomy – how can platform engineering strike the right balance_

As API governance expertise goes, few individuals have more to share than industry stalwart James Higginbotham. The author of Principles of Web API Design and founder of LaunchAny recently joined the Tyk team and other industry leaders at the LEAP 2.0 API governance conference, sharing his insights and strategies in the form of an API governance survival guide. 

Below, we’ve rounded up essential practices and strategies for ensuring your API governance becomes an enabler, rather than a roadblock. Read on to discover:

  • The positive impacts of API governance
  • Five recommendations for achieving a transformational API platform 
  • How your API governance can drive decision-making aligned with business goals 

The state of API governance in 2025

API governance is the framework of policies, processes and procedures that organizations implement to ensure their APIs are designed, developed and managed in a consistent, secure and efficient manner aligned with business goals and business architecture. 

API governance has three positive impacts:

  • It helps organizations define their values and how these will impact the ecosystems and people they serve.
  • It is a force multiplier, with an API provider team’s work having a positive impact on API consumers – on organizations that are using the API, individual developers who are using it, product managers who are leveraging it and more. 
  • It creates opportunities for coaching, resulting in individual career growth, as governance helps people understand more deeply about APIs and their dynamics. 

Five recommendations for achieving a transformational API platform

When you make practices optional, you open the door to inconsistency. You risk delivering the wrong thing in the wrong way at the wrong time. Variation is good, certainly, but you need a primary procedure or standard. You can then implement secondary ones to fit common situations, along with clear guidance that prevents teams falling into the pit of analysis paralysis. 

In terms of standard guidance, the following five recommendations can support you to achieve a transformational API platform:

  1. Align with business architecture 
  2. Create multiple engagement models
  3. Scale your efforts with federated API coaches
  4. Collaborate with other practice areas
  5. Establish API pillars

Let’s break each of these down a bit. 

Align with business architecture 

Governance policies and practices can really drive business effectiveness, so it’s crucial to align governance efforts with business goals and architecture. 

APIs are digital doors into your organization, whether those doors are external or internal doors into a particular domain area or line of business. This means your API platform needs to combine your IT capabilities with your market-centric business capabilities. 

The API governance survival guide image1

It’s time to think about your API consumers here. Your consumers don’t care if you’re using Kafka or not, or what kind of database you’re using, or what your data model looks like. What they want is to be able to interact with your API platform and deliver digitally, either in an automated fashion or in a guided fashion. They want experiences that turn your business capabilities into platform capabilities. 

Your governance can drive this. For it to do so, you need to look at your API platform and think about how you can express your business as APIs – as a topology of the different capabilities. 

The API governance survival guide image2

You can use your governance to define this structure, mapping a domain taxonomy to the paths on your API gateway and grouping things together. To use a very simple example, if you had an insurance business, you could create at least one API for shopping and quoting, one for policy management, one for customer account management and so on. Those APIs would then have services behind them, decomposing complexity, orchestrating workflows and so on.

Thinking about the topology – the business architecture – also necessitates thinking about which digital ecosystems, partners, customers, internal workforce members, internal automations and so you need to support. You need to consider how they all participate in using those APIs, whether through a web app, mobile app or some other means. If you’re a regulated business, for example in the banking sector, you’ll also have to think about consumer interoperability and data portability, along with your partners, workforce ecosystems and maybe even service provider ecosystems. Your governance needs to factor in all of this. 

Essentially, you need to understand the digital capabilities you need to deliver, break them into steps and then create an API lifecycle that designs, delivers, refines, gets feedback and grows that over time. It’s about aligning your business architecture and digital ecosystems and then baking that into your governance. 

Create multiple engagement models 

The API governance survival guide image3

There are many different ways you can engage with teams around API governance, using different solutions to deal with questions and feedback with different levels of complexity. Microsoft Teams or Slack might work for quick governance queries, for example, while specific times for chat sessions might work better for more complex queries. As your investment gets deeper, you might need coaching sessions or even a more ‘white glove’ treatment, such as a facilitated series of design sessions that helps teams navigate that lifecycle, applying governance processes and standards appropriately. 

Scale your efforts with federated API coaches

Scaling this leads to the idea of a federated API coach program. This ties in with federated API management; you can federate governance and enablement at the same time. It moves you from everyone directing questions to one team or resource, to having a centralized group that can make decisions that reflect the entire business: a federated model. 

The API governance survival guide image4

Federation is essential here, because a distributed team model won’t work at enterprise level. You end up with distributed governance teams taking their own approaches, resulting in a lack of consistency. Different teams will approach authorization differently, for example. 

Federation means you can have coaches who represent or liaise with your central governance body – the API Center of Excellence (COE) in the above diagram. You can stand up coaches in different business domains, in whatever ratio suits the size of your business and the experience levels of your teams. This federated API program approach lets you tap into people who are passionate about APIs and who understand aspects of the domain area, who can them be available to support your teams. The federated team is there to:

  • Maintain and support the API program and processes
  • Assist teams to design reusable APIs within and across the domain
  • Facilitate API design sessions and office hours for engagement
  • Apply API standards, conventions and guidelines locally

Your coaches can also feed back to your Center of Excellence when things aren’t working as expected – when you need better examples in the standards or better tooling, for example. 

Collaborate with other practice areas

Governance is nothing new. There are already layers of it across your business. At the center is your business strategy – the business architecture that’s driving everything. That’s the foundational element of your overall API platform, with your platform engineering practices, tools and automations all fitting with it.

Then you have your governance practices and standards, for your APIs, events and streams async APIs and so on. 

After that layer comes your business capability platform. These are the platform APIs that represent how you do business, your workflows, your vocabulary across all the different domains and lines of business, which carry through your APIs and streams. 

Then you have your digital ecosystems – the different areas that you’re engaging with, the apps people are building or integrating with via your API integrations, building on top of your business capability platform. 

The API governance survival guide image5

Understanding these layers can help you think about governance more clearly. You can see where policies fit, whether they’re impacting internal or external ecosystems (or both) and so on. 

You’re not alone in doing this. There are a number of different practices within your organization that all need to do the same thing – your datasets and data products, trust frameworks, security models, engineering practices, emerging AI practices and more – all those involved in these are potential collaborators. You don’t need to build in isolation, so leverage those collaboration opportunities to drive your governance. 

The API governance survival guide image6

Establish API pillars

You need a way to determine if you need to implement particular standards or policies as part of your governance. That means it’s time to think about the pillars that are standing up your API platform efforts. Pillars are broad statements that outline your organization’s core principles and areas of focus, helping drive successful operations. When you put these foundational elements in place, they help you define your policies and your expectations, the scope of which can span the entire business, a specific line of business, a domain, a business unit, an issue or a system. 

API pillars relate to three key areas:

  • API strategy and enablement, where pillars relate to the platform strategy, business alignment, governance and the enablement associated with the API platform
  • API management, where pillars relate to the ownership and management of the overall API platform and individual platform APIs
  • API operations, where pillars relate to the security and operations of the API to ensure that all platform APIs are continually evaluated for proper security measures, optimized deployment and continuous monitoring and improvement 

From here, you can map out your strategy, practices, design and full API lifecycle. Pillars cover eight main areas: 

  • Strategy and business alignment
  • Governance and enablement 
  • Portfolio and domain ownership
  • Discovery and documentation
  • Design and delivery
  • Consumer onboarding and adoption
  • Security and operations
  • Runtime management and monitoring 

These are all the aspects you need to think about when shaping your API governance. They support you to define your pillars and policies in a way that establishes expectations and provides a decision framework. So when your delivery teams are trying to figure out what aligns with your business goals, these pillars and policies will drive those decisions. They will enable your teams to walk, run and fly as the business scales. 

Where next? 

Ready for more input to guide your governance to be the best it can be? Our article on how to implement API governance without stifling developer creativity is a great next step.