---
published: true
layout: post
title: My API Governance Narrative For APIdays Insider NYC This Evening
tags:
  - Conferences
  - Events
  - New York City
image: https://kinlane-productions2.s3.amazonaws.com/apidays-insiders-new-york-1.png
---
My name is Kin Lane — I am the guy who has been paying attention to the technology, business, policies, and people of APIs since 2010. I am best known for my API research, consulting, and storytelling as the API Evangelist, but I have also worked with US federal agencies and the European Union on API standardization. But you might also know me as the Chief Evangelist and Director of Open Technologies at Postman between 2019 and 2023, but most relevant to this crowd, I spent the last year standing up an API governance program at Bloomberg here in New York City.

### Modern HTTP APIs
In my work I am exclusively focused on HTTP APIs and Webhooks in my work. I am not interested in GraphQL, Kafka, gRPC, or other technological excursions. I am only interested in standardizing HTTP APIs, which according to Akamai powers 83% of the Internet, and likely 50-75% of any enterprise organization. I am interested in the digital supply chain, factory floor, and distribution channels for enterprise desktop, web, mobile, device, and AI applications, and making sure digital resources and capabilities are available in any system we all need to get our business done.

### API Governance
My view of API governance is more akin to a combination of governing a country and controlling the velocity of a very large steam engine. API governance is much more than just the design and consistency of your APIs, and is something that will require the governance of not just enterprise systems, but also the people who operate those systems. API governance is about finding the right amount of fuel and velocity to operate your enterprise, but also the right policies and guidance to keep business and technical stakeholders all moving in the same direction. Ensuring that everyone is speaking the same language and consistently delivering whatever is needed to adapt to each market moment we all find ourselves living in.

### The API Landscape
I am interested in governing the entirety of our HTTP APIs, which means I am governing the design and consistency of APIs, but just as important, I am also governing the teams, operations, and API lifecycle around them. API governance begins with mapping the HTTP API landscape as it exists, defining APIs as OpenAPI to help understand the technical details, and API operations as APIs.json to help understand the business details. The modern API landscape map is created and iterated upon in real-time using common open source and machine-readable API specifications that live in source control, and are automated using APIs, webhooks, and CI/CD pipelines.

<img src="https://kinlane-productions2.s3.amazonaws.com/apidays-insiders-new-york-2.png" style="padding: 15px;">

### Policies, Rules, & Lifecycle
Once I have even the beginning of an API landscape map I get to work defining a base set of API governance rules that provide a baseline of API patterns and anti-patterns that exist across the known API landscape. These rules will help automate the governance of the technical details like casing of schema properties, and HTTP status codes used for responses, but also the business details like documentation, SDKs, and rate limits. These rules are then organized using a machine-readable set of policies that speak to real world business outcomes, and are organized in a consecutive series of development stages according to a common agreed upon API lifecycle. 

### Business and Technology
The mainstream API governance discussion today is heavily focused on the technical details of doing APIs because us technologists are the ones leading the conversation. I am looking to spark more energy for collectively doing the work to bring in business stakeholders and map the hundreds of individual rules to business objectives using API policies–providing the business rationale behind why we are doing API governance in the first place. Without this business alignment API governance tends to move in the wrong direction, and will be missing many of the nutrients needed to power what is next for the enterprise when it comes to doing business in an increasingly digital world.

### Specifications & GitOps
My API governance approach is heavily focused on mapping the API landscape then governing the technical and business details of enterprise API operations using common API specifications like APIs.json, OpenAPI, JSON Schema, and Spectral via Git. There is just too much ideology and dogma wrapped up in the decisions and beliefs surrounding the existing infrastructure, services, and tooling in use across the enterprise. I rely on HTTP APIs, Webhooks, and Git to seamlessly weave API governance into existing API operations, while keeping API governance delivering using specifications and a GitOps approach.

### Developer Experience
Let’s talk more about why we are doing all of this–API governance is how we are going to standardize and stabilize the developer experience, making production and consumption of APIs easier, faster, and much more frictionless. API specifications are how you generate code, configure gateways, publish documentation, deliver SDKs in a variety of programming languages, test, and secure your APIs across the enterprise. The experience of producing and consuming APIs across the enterprise will shape how successful any modernization of operations will be, and dictate how well an enterprise is able to keep up and compete in new areas like artificial intelligence.

<img src="https://kinlane-productions2.s3.amazonaws.com/apidays-insiders-new-york-3.png" style="padding: 15px;">

### Policy-Driven Governance
Like APIs, your API governance must be ever-evolving to keep up with the pace of change. Modular API rules aligned with API policies that perpetually align with shifts in the business landscape, and applied as part of well-known and common API lifecycle is how you continue to adapt. A policy-driven approach to governing APIs that is supported with Just-in-Time API Guidance for teams is how you automate your digital supply chain, factory floor, and distribution channels in a way that is configurable by teams along the way, while being standardized and aligned with business operations perpetually over time.

### Building Your Platform
Just a reminder. I am here to help you build YOUR platform. I am NOT building the platform of the leader of the latest technological trend. I am NOT building the platform of the latest round of venture capital, only to dissipate with each wave of exits. I am here to invest in YOU building YOUR enterprise platform. I am interested in mapping the landscape across your enterprise using common Internet, industry, and API standards, and governing the seamless integration of that landscape with the best in breed infrastructure, services, and tooling that have been adopted across your teams, and are already what your customers are using in their own businesses. 

### Federated and Centralized
Now before I finish, I also want to talk about this perpetual desire to centralize and platformitize everything across API operations. While there is a time and place for centralization and a time and place for a more distributed approach–there must always be a balance. Policies, guidance, and tooling should be as centralized as possible, reducing teams reinventing the wheel when it comes to design, authentication, security, and other common aspects of a modern API experience. However, teams operating in isolation also have the potential to bring agency and autonomy–with the right governance policies, rules, and guidance in place, it can also bring accountability, aligning business and engineering operations while still allowing teams to confidently move fast without breaking things.

### API Chaos & Sprawl
When I started as the API Evangelist in 2010 I was urging everyone to do more HTTP APIs. In 2024, I am urging everyone to govern their HTTP APIs, but in reality this is all actually about governing the enterprise. API sprawl and chaos is the default state of the enterprise in 2024. HTTP APIs are the digital supply chain, providing the raw digital resources and capabilities a business produces and purchases from their API suppliers. The API lifecycle is the digital factory floor of any business, with the developer portal acting as warehouse and wholesale distribution center, and leverage web, mobile, and AI applications acting as the retail face of today’s business.

API governance isn’t just about standardization and consistency of APIs. It is about standardization and consistency of enterprise operations and teams. You’ve personally made 10 to 20 thousand API calls today on your mobile phone and the applications you use on your laptop, just like you use electricity, water, transit, and other already standardized systems that make our world go around. APIs are cross-cutting, universal, while also being very hard to see, and APIs will also require the same standardization that these other industries have gone through to take them into the future and created entirely new markets. API governance isn’t just about taming the API chaos and sprawl, it is about embracing it and allowing us to grow bigger, move faster and further than we have with our ungoverned API infrastructure.