---
published: true
layout: post
title: I Am Just an API Surveyor and Assessor
tags:
  - Landscape
  - Mapping
  - Governance
  - Discovery
  - Surveyor
  - Assesor
image: >-
  https://kinlane-productions2.s3.amazonaws.com/algorotoscope-master/yellow-journalism-central-park-winter-walkway.jpeg
---
I am struggling with how I communicate about what I do, and the value I bring to the table. My perspective of the API universe and what I offer aligns sometimes with the popular vendor narrative and what enterprises are accustomed to being sold, but it also doesn’t in many ways. I left Postman looking for more learning at the intersection of API products and API governance, and I found it at Bloomberg. I came out of the gate at Bloomberg convinced I was going to do API governance as a service. I learned a lot and left eager to repeat the spec-first GitOps approach to API governance I proved out there, but this time with multiple enterprises across other industries. However, I am not sure I’d call this API governance, so I am exploring new possible labels like API surveyor and assessor.

My work in API governance moved on significantly from the wider vendor-backed discussion around API governance today. What is being sold as API governance is a very linting and rules-based, offering a technical approach to ensuring that every API is as consistent as possible. After having conversations with enterprises about their API operations on my Breaking Changes podcast I saw early on that a purely technical approach would not be enough, and that this very complex and technical sprawl would need to be aligned with the business reasons for why APIs exists in the first place or should continue to exist. The current round of API governance that is being sold to IT administrators who do not consider or always care about connecting the dots with the rest of API operations, let alone business operations. This is acceptable to most who are involved, as long as it is in support of services being sold in a top-down or bottom-up motion and matches what investors are looking for.

The services I am building for the next phase of my career begin with the discovery, aggregation, evolution, review, and certification of API artifacts in a Git repository. This is done using OpenAPI + Spectral rules, which overlaps with the current notion of what API governance is, but I also apply APIs.json + Spectral rules which expands beyond individual APIs and looks governs API operations. This expansion of API governance begins to collide with other existing notions of governance within the enterprise, such as data governance, compliance, and even security. So I hesitate to call it API governance. I am mapping the API landscape, which is needed for every aspect of API operations from design to documentation to security, but I am not applying rules to govern what vendors are selling to enterprise IT leadership. My API landscape mapping, rules building in service of pattern and anti-pattern matching, and publishing of API artifacts into a Git repo is much more about surveying and assessing the API landscape so that one can eliminate redundancy, modernize their legacy, or simply just reduce the cost operations-—the primary focus is not really in the service of centralized platform governance.

<img src="https://kinlane-productions2.s3.amazonaws.com/algorotoscope-master/yellow-journalism-old-tower-buildings-light-nyc.jpeg" style="padding: 15px;">

I enjoy making sense of API sprawl. I am good at making sense of API sprawl. I believe it is important to govern APIs at scale, but not necessary to platformitize and make them all the same. I believe in identifying healthy patterns as well as anti-patterns. I believe in interoperability and standardization at the Internet and industry levels, and encourage it at the enterprise level. I strongly believe we’ve embraced more complexity which is required for APIs by not properly making sense of and properly investing in HTTP APIs and Webhooks. I genuinely want to map and understand the API landscape so that we can see it and have a productive conversation about it. I have crafted a suite of services around all of this, delivering the following:

- **Schema** - The management of standardized schema within a GitHub repository.
- **APIs** - The management of standardized API contracts within a GitHub repository.
- **Rules** - The development of rules that define the technical details of the API landscape.
- **Policies** - The development of policies that define the business details of the API landscape.
- **Experience** -  Identifying how API operations are delivering or not delivering experiences.
- **Reviews** - Conducting reviews on schema and APIs using various rules and policies.
- **Certification** - The certification of the technical and business details of APIs and schema.

This is my toolbox. Everything here is schema-driven and delivered using Git. It can be seen as API discovery, governance, security, and benefits almost every other area of API experience. I can come into any industry or enterprise and apply these services. The big question is, why would someone pay me to do this? I am not interested in building a product around this, just a set of services. There is nothing proprietary about each of these services, just the expertise in how it all goes together, and in which order things are implemented. I have been calling what I do API governance because that is the closest thing to what is currently being sold on the market, but honestly I feel much more like an API surveyor and assessor of the enterprise as well as industry landscape. Governance is the closest way to describe what I am doing, with API discovery being the second closest phrase. I’d say that I am an expert in API discovery, and quickly becoming an expert in API governance as it applies to the entire enterprise or industry landscape.

I will apply my trade to any industry—I am currently doing this to social media, credit cards, artificial intelligence, and Blockchain. I can do my work from the outside-in, or the inside-out. The trick is finding someone to pay for it. I have to find an enterprise who sees the value of mapping the schema and API landscape across their operations, craft the policies and rules that align with their business, and review, certify, and help them shape the experiences offered. Not everyone is ready for that or honest about that. I also can apply the same approach from the outside-in, mapping out the public presence for API providers, as well as their competition within their industry. The trick is, who will pay for that. Right now I am doing it under the banner of API discovery, but really there is no money in that. It is interesting that when I am selling it to the enterprise internally I am calling it API governance, and when I am doing it publicly I call it API discovery. When it is reality I feel pretty strongly that it is both and neither—this is why I am exploring the concept of maybe I am just an API surveyor and assessor--someone else will levy the tax of governance.