I was just exploring how I got here as well as where I am going, and I have only a few more process based posts left to publish here in 2024 before I move into demonstration mode during 2025. I am very aware that there are a finite number of people who care or understand what I am talking about, and this is fine. These folks can connect to learn more about the 100K of things, but in 2025 I will be drip, drip, dripping with strategic and tactical stories, guidance, and artifacts that connect the dots across the landscape I am seeing. With this said, I have a few more 100K view posts to get out of my head as I continue work on v4.0 of API Evangelist, with this one connecting the dots between all the building blocks of where I am taking API Evangelist in 2025.
This diagram represents five years of thinking about API operations, lifecycle, and governance, but let me see how well I can do to help connect the dots here and articulate why my approach in 2025 will be different from what others are doing in the space. The red boxes represent the status quo when it comes to API governance, and some other API services being sold, with the green boxes representing isolated conversations that have been occurring in the space for some time, but the purple boxes are very much my individual contribution to the API discussion—let’s break down each box.
- Strategies - The highest level of business thinking (ie. better secure operations, generate more revenue, etc.)
- Policies - The individual business details of API operations ( ie. change management, quality, consumers, etc.)
- Experience - The details of human experience producing and consuming APIs (ie. onboarding, authentication, integration, etc.)
- Properties - The specific elements of API operation (ie. documentation, JWT, SDKs, etc.)
- Lifecycle - The order and sequence of when things happen in API operations (ie. design, develop, staging, production)
- Rules - The individual tech details of API operations (ie. status codes, parameter names, operation summaries, etc.) (Spectral)
- Contracts - A machine-readable representation of the business details for a single API (APIs.json)
- APIs - A machine-readable representation of the technical details for a single API (OpenAPI).
- Schema - A machine-readable representation of a digital object (JSON Schema).
- Services - Commercial services that are sold to satisfy operational needs. (Commercial)
- Tooling - Open source tooling that is designed to satisfy operational needs. (Open Source)
- Stories - One to three paragraph stories w/ supporting artifacts on any topic. (Blog)
- Conversations - Recorded conversations with individuals about their API experiences (Podcast)
- Guidance - Text, videos, and artifacts that guide API producers and consumers forward on a single concept.
The majority of discussion around API governance today is focused on APIs + rules, with a mix of tools and services to automate what is needed. Very few folks are reconciling the JSON Schema and Spectral rules, and how you and where you validate or lint. Nobody is defining API contracts at an operational or business level and API contracts only mean the technical details to folks. People are having conversations about strategies and the life cycle, as well as a handful of experiences in isolation, but nobody is connecting the dots between which rules address specific experiences, or how any of this translates into business benefits. There are just big hand-wavy gestures towards APIs that helping you with business—-I am looking to draw a direct line between all of these areas, while providing guidance, driving conversations, and telling stories about it.
It isn’t easy to draw a line between being adaptive as a business down to a linting rule for versioning of an API. It isn’t easy to identify how documentation impacts the business bottom line, as well as the Spectral rules that line for OpenAPI summaries and descriptions in your operations. There isn’t much discussion about what stage of the API lifecycle should you have examples present in your OpenAPI for all of your requests and responses. There is a well-known set of schema to describe the technical details of API operations with many more specifications emerging on a regular basis, but almost none that will speak to the strategic, lifecycle, experience, and policies that shape the business of our API operations. This is a problem. We have no way to express in business terms the rules we are defining to lint our APIs. We have no way to express in business terms why JSON Schema will help stabilize our businesses and bring more velocity. These are problems. These aren’t technical problems. They are communication problems. We need stories, guidance, and more conversations, with artifacts that ground what is happening.
If an API costs us $50K to build, and an enterprise organization has approximately .5 APIs per employee, what policies will help us make more money or save money? If an industry adopts a standard for the APIs that exist, how will we quantify the cost savings in generating SDKs and automating integrations? There are so many interesting questions at the intersection of product and engineering across API operations, but few who will ask these questions, and even fewer who have the answers to these questions. The 2025 vision for API Evangelist is all about asking and answering these questions in quantifiable and demonstrable ways. I am not looking to come up with a new specification to rule them all or a new process that gets everyone believing, I am just looking to connect the dots between individual technical details of API operation with the individual business details of API operations, and tell stories, engage in conversations, and provide real world guidance for each bridge we need to build between product and engineering.
