To augment my how I got here post, I want to explore where I am going with the next fifteen years of API Evangelist. I have all the building blocks for the next portion of my API journey, I just need to organize them into a set of services that will make sense to where various enterprise organizations are in their API journey. I am confident that I have the building blocks to help contribute to the API operations of almost any enterprise organization or startup, but I need to find the areas of business strategy and experience that matter most to business leadership right now in this very chaotic and sprawling global digital landscape.
I’ve done the work on the technical details of this approach to talking about and delivering APIs, and begun the work on the business details, but the product and business leadership side of this narrative is the least fleshed out. Schema, APIs, and rules in this narrative reflect where the largest portion of my work occurred in 2024, and now in 2025 I will be looking to strengthen the business reasons you should be investing in your API operations. Each of the following areas reflect how I intend to continue reverse engineering the status quo for API operations today into the business argument for why API investment matters.
Schema
JSON is what powers enterprise operations, defining the digital objects we are passing back and forth as part of systems, applications, and integrations. JSON Schema is how these digital objects are defined and validated ensuring the quality of service that enterprise engineering leadership desires. Helping enterprises define, manage, and evolve their schema in centralized and federated ways is one of the top areas I will be working with API producers. Surveying and assessing the schema landscape for enterprise organizations is the quickest way that I can have an impact on API operations, as part of my API Evangelist journey.
APIs
Overlapping, but also expanding on schema work, I will be helping manage APIs using the OpenAPI specification. A single source of truth for an API, defined by a complete and accurate OpenAPI augmented with overlays and workflows is what every enterprise is needing today to deliver the applications and integrations they need to power their business. Along with, or separate from schema, I will be helping create, refine, and evolve the OpenAPI for one or many APIs via Git. My API services will focus on just specifications within Git, but the policies and rules applied at various stages of the lifecycle to these artifacts will power much more.
Operations
My approach to API governance went beyond the individual API while working at Postman, and was a position that was solidified during my time at Bloomberg. Every aspect of API operations, lifecycle, and governance must expand beyond the surface area of APIs and include the rest of engineering and business operations. I am looking to take what JSON Schema, OpenAPI, and Spectral has done for API operations and expand all of it to include wider business operations using APIs.json. Defining API operations using APIs.json, and aligning the product and engineering motions within the enterprise is my top focus.
Standards
APIs are just the evolution of the web, and are driven by a handful of standards like HTTP, OAuth, JWT, JSON, YAML, OpenAPI, and JSON schema. Helping enterprises understand and maximize their adoption of these standards and even contribute back to these standards is an important area of my ongoing work. This API standards work begins with identifying and educating existing teams about the API standards they are already using and making sure they are using the latest version of each standard. From there, I will be continuing to bring in standards like Problem Details for errors, and other emerging patterns targeting APIs.
Policies
The bridge work between product and engineering groups are defined using policies, articulating everything from authentication to which error codes return, and the support and pricing available to API consumers. API policies speak to the business strategies and the desired experience intended for consumers of an API, establishing a precedent for why something is done as part of operations, with all the references to the technical details, guidance, and whatever else is needed to define, shape, and evolve API operations to support the current business climate—building a bridge between product and engineering one policy at a time.
Rules
The technical details of each individual API is currently being defined using Spectral rules, and I have 400+ rules that cover the most common patterns and anti-patterns for HTTP APIs, as defined using an OpenAPI. These rules are applied during design-time in various editors, at development-time using IDE and CLI, and during build-time using CI/CD pipelines. However, I also apply rules to the operational level using APIs.json, where I am defining, shaping, and evolving how we define and scale API operations. JSON Schema is how we validate all the digital bits, and Spectral is how I am validating APIs and operations across the lifecycle.
Strategies
API strategy is widely referenced in the space but I find is very seldomly ever actually defined, let alone something that is actually mapped to the reality on the ground within API operations. I have done the early work to reverse engineer many common API strategies associated with the policies and rules surrounding HTTP APIs. I have a lot more work to be done in 2015 to flesh out strategy and policies as much as I have rules, but the groundwork is there for connecting the product and engineering dots. I am confident that my approach to bridging business strategy to technical details of API operations is something that will speak to leadership.
Experiences
Complimenting my strategy work I have begun the work to connect individual rules to actual human experiences producing and consuming APIs. OpenAPI summaries and descriptions can be linked to documentation, examples can be linked to mocking and sandboxes, with OpenAPI operationId linked to SDK generation—-which can all be linked back to onboarding, integration, discovery, and other real world experiences that may be increasing friction across API operations. Experiences are how I am mapping the human aspects of API operations to the business and technical details via common policies that help shape API experience.
Lifecycle
Overlapping the product and engineering alignment available with the strategies, policies, rules, and experience work, having an agreed upon definition of when something should happen in the lifecycle of a new or existing API, can introduce some very stabilizing effects on teams producing APIs. I don’t care what the stages are in the life cycle, or having strong opinions on what should happen at each stage, I am concerned that each stage is defined, and that policies and rules are being applied at logical stages across the APIs within a domain—-making the API lifecycle a known and agreed upon series of events moving toward production.
Stories
All of this work requires storytelling. My storytelling moving forward will be 25% about the process, and 75% demonstrating how it is done. Everything I’ve learned and shared over the last fifteen years has been via storytelling on the web and via events. This part of the equation will go unchanged, and a regular stream of blog posts, white papers, and talks will be the default storytelling cadence for API Evangelist. My goal moving forward is to keep stories simple and focused, with the accompanying artifacts needed to actually apply what is being told in the story, making each one a hands-on opportunity to demonstrate something useful.
Conversations
Zoom and podcast conversations have always been a regular part of my work, and will continue to support and validate my work. I will keep driving conversations with API producers and consumers about what they are experiencing on the ground, while also opening up the conversation for other API service providers who are delivering services and tooling to the space. All public conversations are recorded and transcripts published to help contribute to the overall knowledge informing my work on schema, APIs, operations, standards, policies, rules, strategy, experience, and lifecycle, rooting my storytelling in what I am learning.
Guidance
One of the most deficient aspects of producing and consuming APIs is the lack of documentation and relevant guidance to move things forward. I strongly believe that API guidance must be published as centralized content and videos for teams to consume, used as part of webinars and workshops, but should also be one click away from any rule, policy, and friction across any API experience. API Evangelist guidance is simple textual, video, and artifact driven guidance that is clickable whenever a rule governing API operations or each individual API is encountered, ensuring there is Just-in-Time guidance available across API operations.
Services
Each of these areas listed above represent a possible standalone service I can offer to my customers. Each area is defined by a set of commons schema and guided by a set of Spectral rules, and can be delivered via a Git repository. I can deliver services within each of these areas, but the output of my services will always be an APIs.json, OpenAPI, JSON Schema, and the policies, rules, and other artifacts used to govern API operations. These services will be augmented by an additional set of partner services provided by API Evangelist partners to deliver whatever is needed across every stage of the API lifecycle by my customers.
Tools
My approach to surveying and assessing the API operations of enterprise organizations is built on top of as many open source tools as possible. Starting with Git, and the command line tooling I use to manage source control across any schema, API, or operational definition I am managing. Documentation, client, and other aspects of my API work will leverage open source tools like Redoc and Bruno, with open-source API specifications as the glue connecting it all with the services me and my partners will be offering. My goal is to help my customers invest in their own API platform, and minimize building other vendors’ platforms.
Surveying
I have been calling what I do governance, but I am leaning more towards simply calling it surveying. With the above services I can map the API landscape of any enterprise from the inside-out or from the outside-in. Granted, I’d prefer to be paid to survey the APIs that exist by an enterprise, but mapping the public landscape will also play a significant role in my next generation of API services. This is why API governance doesn’t work to describe the value I offer in 2025, and is something that I will be demonstrating as I profile top API producers in the credit card, AI, Crypto, social, and other top industries, to showcase what my services can do.
Assessment
As I survey the API landscape within a single enterprise or industry I will also be actively assessing the landscape using Spectral rules. This is the same practice employed as part of API governance, the difference is that when I do it from the inside-out it can often be called API governance, and when I do it from the outside-in it is considered discovery or now simply surveying. I will still apply Spectral rulesets looking for the most common operational, API, and schema patterns and anti-patterns, linking the experience, policies, and guidance behind them as I would with any API review process conducted as part of internal governance.
API Evangelist
If I had to put a version on API Evangelist, this would probably be version 4.0, with 1.0 spanning 2010 through 2013, and 2.0 spanning 2014 through 2018, and 3.0 spanning 2019 through this year, and with the biggest shift now being towards 4.0. This version of API Evangelist is all about HTTP, JSON, YAML, OpenAPI, JSON Schema, APIs.json, Spectral, Markdown, and Git. This is what will be selling to the enterprise in the shape of each area outlined above. While I would prefer my customers approach this from a strategic perspective, I am happy to accommodate tactical investment in API operation, providing an À la carte set of API services.
My API Evangelist storytelling has always been informed by the profiling of, and having conversations with API producers and consumers, and this round I am just being more performative with my work by turning API Evangelist into my toolbox. I’ve long said what my blog was, now I am just adding the other artifacts I use to make the magic happen. I will focus on the output of my work being machine-readable standardized artifacts, combined with storytelling and guidance, all published in a git repository. This is how I will continue to define my work, and have an outsized impact on how others are producing and consuming APIs today.
