Weekly API Governance (Guidance)
My name is Kin Lane—I am that API Evangelist guy who has been paying attention to the technology, business, policies, and people of APIs since 2010.
It is a holiday weekend in the United States, so this week’s newsletter will be short and sweet. I love how the holidayz can disrupt time and space. It is a time of year that I love most because of the food, but also how the business world shuts down, allowing me to move forward the projects I am most passionate about for the new year!
Discovery
As part of my recovery from the election, I am back to my usual bullshit profiling the APIs that exist within the United States federal government. The opportunities involving digital resources coming out of government APIs are massive, but it is one that is difficult to see unless you are in the know of how government works, and frequenting their digital domains looking for API gems!
Another observation I had from profiling government APIs, but also other public APIs this week, was that there are a lot of inactive public APIs out there. I coined the phrase “haunted house API” (which I think will go viral big time) this week to describe the numerous portals I came across that hadn’t had an update in months or years and there was nobody home answering questions—leaving just faint echoes of what might have been.
Services
As I prepare the one sheet and demo project for one of the fundamental services I will be offering in 2025, I workshopped some more ideas around getting your enterprise schema house in order, which is a topic I’ve been evangelizing since early 2017, but recently made one of my foundational API Evangelist services.
JSON Schema and JSON are the fundamental unit of the entire economy (not an exaggeration) which very few people can actually see. Investing in the fundamentals when it comes to centralizing schema in a central repository, defining them as JSON Schema, then governing and reusing them across operations is one of the most stabilizing things any company can do in this moment.
Applications
A foundation of my API Evangelism over the years is focused on the reuse of digital resources and capabilities across desktop, web, mobile, device, and network applications. I am regularly, but thoughtfully adding to this stack (schtick?), with artificial intelligence being the latest one, and now Terraform API calls, or more broadly Infrastructure as Code.
This adds to the many ways in which we are “applying” our digital resources and capabilities, so I added APIs being used as part of Infrasstructure as Code (IaC), and put some thought into how API governance rules might apply to APIs in this situation. I may not add IaC to my regular hustle poetry, but it is one place I’ll be spidering, harvesting, and looking for evidence of APIs on GitHub.
Governance In Terms of the Bottom Line
Translating API governance into business speak is what my current work is all about. To help me craft a sophisticated algorithm (if/then statements) to calculate the cost of doing or not doing API governance I wanted to answer two key questions this week:
Next, I will need to answer things like, how much does it cost to integrate with an API, and how much revenue does an API directly or indirectly deliver, but this is a damn good start.
These metrics will provide me with way to calculate the cost of API governance—I just need to attach scope of cost to each building block of delivering an API (ie. code, gateway, docs, security) to round off my algorithm.
Is What I Do API Governance?
Claire Barrett of APIsFirst asked me this week if what I offered was indeed API governance, and whether or not enterprises would confuse it with other forms of governance. She is spot on with her assessment. 1) What I am selling is much broader than what others sell as API governance—it has more business and more ops. 2) The phrase easily collides with data governance, regulatory compliance, and even security in my experience.
This line of questioning reflects the scrutiny I want to put my own work under tis month, and I will be engaging with Claire for further discussion here in December. I will also be wrestling with the possibilities of calling myself more of an API surveyor or assessor, who is just mapping the landscape rather than governing it. Additionally, I am neck deep with the Bluesky API right now, and having flashbacks and hallucinations of APIs circa 2012, so there will be a blast of Bluesky API related work and stories this week.
