Friday was my last day at Bloomberg. I learned what I had come there to learn and now it is time for me to get back to my API Evangelist work. Moving forward, I will be taking my previous API Evangelist foundation, combining it with what I learned at F5 and Bloomberg (both enterprises), but also what I learned at Postman (a startup) through my conversations with numerous enterprise customers, as well as via my 125+ Breaking Changes podcast episodes, then applying it all as a new podcast (kinda sorta) and a set of API services focused on helping the enterprise govern API operations.
When I left Postman to work at Bloomberg I was determined to test out a handful of concepts I had learned while talking to enterprise API practitioners, and I really wanted to get my hands dirty doing what I had been talking about for the previous decade. I did that at Bloomberg, but to fully understand my journey to this point in time, we have to go back to 2019, where I put API Evangelist on hold to go get a job. I had a kid who needed to go to University, and another kid who was struggling with addiction. I went to work at F5 Networks, where I learned a lot about how the enterprise approaches API operations at scale, and then I learned about the opportunity with Postman and quickly moved to the Bay Area just as Covid took hold of the world.
During Covid I worked very hard. We lost my wife’s son to an overdose and one of my best friends to suicide. I worked even harder. By 2023 I was burnt out and in desperate need of change, but I also wanted to learn more about the two top areas of conversation I had been having during my Breaking Changes podcast:
- Narrowing the gap between business and engineering when it comes to delivering APIs
- Defining what API governance means at scale across API operations via an API Platform
I got to experience this at Bloomberg. I am grateful, and I am confident that the base I stood up will continue having an impact there, as well as just my presence and personality for a little over a year. However, we now have a kiddo who graduated, and we are doing the hard work to heal from the loss of our other kiddo. I miss writing. I miss writing 100% in my own voice. I am also confident that I now have a new set of services that the enterprise will need—-which I can use to sustain my work. I am not looking to do a startup, I am just firing up my API Evangelist small business again. I’ll also be continuing to invest in APIs.io, API Commons, and APIs.json. I am going to resume doing a podcast. Really, it will just be regular recorded conversation about what people face across their API operations. I’m going to keep each episode to less than 15 minutes a piece, and I will be prioritizing API consumers and API producers over API service providers. I want to focus on the business and engineering folks on the ground floor who are just trying to get the API work done each day.
I am confident that I can make a good living with the set of services that I’ve cooked up–I’ll talk more about them in September. I’ll just be writing for the next couple of weeks, processing all my notes from across the last 5 years. I am open to having conversations and I have opened up some slots each week in my calendar. I’d like to record some conversations for launching my new podcast in September, and I am interested in API discovery, lifecycle, and governance discussions. Feel free to ping me at [email protected]. I am open for conversation now, and open for business in September. But, this round I am going to be much more protective of my time than I was for the last round of API Evangelist. I am on a mission. I have a vision. I am eager to stick to it, and I have a ton of work to do across API Evangelist, APIs.io, and the API Commons.
I will continue telling stories on API Evangelist as I always have, but instead of selling my writing, speaking, and producing events, aka my API evangelism schtick—-I will be focusing on API contracts using APIs.json, and common and community properties from the API Commons. I have a set of services that focuses on the following areas of engagement when it comes to API operations across the enterprise.
3rd-Party Inbound
The most common type of API, where enterprises publish APIs publicly via portal for 3rd-party developers to consume and use in their applications and integrations.
3rd-Party Outbound
A very ad hoc and shadowy aspect of API operations, with all of the 3rd-party API consumed by teams within an enterprise to automate, integrate, and use in applications.
3rd-Party On-Premise
3rd-party APIs, but the ones that come with the infrastructure decisions that have been made and run on-premise, providing another opportunity to define API consumption.
1st-Party
The shadowy APIs we developed between web, mobile, and desktop applications, which are often available via public DNS, making for a significant area to standardize.
Internal
The many APIs and microservices that are powering the enterprise, that may mature and evolve to power 1st-party of 3rd-party applications, but likely will never see the light of day.
I’ve broken down API operations into what I consider to be the most common relationships that exist within the enterprise, but aren’t always talked about as part of API lifecycle and governance. This is where I will be focusing when it comes to API contracts, where API producer and consumer come together to get business done. I am eager to take my combined learnings from the last five years and roll up into a suite of strategic and tactical services, combined with ongoing conversations focused on the following aspects of API operations which I have been immersed in for the last couple of years.
- Hands-On Self-Service API Governance - Doing what I talk about along with the API producers and consumers of the APIs that I manage contracts for.
- Business and Technical API Alignment - Being the bridge between business and technical groups producing and consuming APIs across the lifecycle.
- Governing APIs At Scale Across Different Groups - Having the tactical, but also the strategic vision for governing APIs at scale across different groups.
- Specs-Only to Reduce API Politics & Friction - Being 100% focused on contracts and avoiding infrastructure & tooling where politics tends to accumulate.
- GitOps-Driven API Source of Truth - Leverage a GitOps workflow to manage contracts, building on the existing infrastructure used to manage change.
- Importance of API Guidance for Teams - Heavily investing in Just-in-Time API Guidance™ to make sure teams have the education they need right now.
- Establishing a Common API Lifecycle - Ensuring there is a common and strongly typed API lifecycle to make sure everyone is on the same page.
- Doing Multi-Protocol API Governance - I will be only focusing on HTTP, REST, and Webhooks, as I’ve learned a lot about governing other patterns and protocols.
- Evolving API Discovery and Visibility - Taking a different approach to how APIs are made visible and are discovered by both producers and consumers.
- JSON Schema Validating API Operations - Elevating JSON Schema to ensure all aspects of operations can be validated by anyone involved with APIs.
- What Actually Matters to API Leadership - Focusing on what really makes API operations function-—the business, and generating the revenue leaders want.
- What Actually Matters to API Teams - Providing more of a lifeline to the business and technical teams who are doing the work that makes APIs work.
- Properly Defining Your API Platform - Formalizing the definition of the API platform, standardizing the base of API operations for everyone involved.
- Having a Clear API Vendor Strategy - Ensuring there is a strategy for managing API vendors based upon the value they provide across API operations.
- Role of Provenance in Dealing with API Change - Peeling back the onion of change without always crying because you have the provenance required.
I’ve learned what I like doing in the API space, what matters most to API operations, and where most of the friction comes from across the API lifecycle–this bulleted list represents that. This list doesn’t lend itself to producing a simple and straightforward product with which one could build a company around and attract investment. However, I also think it smells of a tremendous opportunity to make money while also helping people get shit done. With this in mind I have been thinking deeply about how I can develop a set of services and eventually some products that reflect these learnings, and I am confident that I have my finger on the pulse of what API governance actually means, and it is not just about governing the design of APIs. Inconsistent APIs are just a symptom of larger organizational, policy, and people issues, and when you govern APIs, you have to actually govern the entire enterprise to be successful.
Much of the conversation across the API lifecycle, including governance, gets defined by API service providers and investors, and a handful of analysts, pundits, and practitioners who dominate the spotlight. I want to shift the narrative to not always be about whatever the investors want, such as API management, service mesh, or artificial intelligence. I want to focus on governing the enterprise using open-source API contracts. I want to focus more on the business of APIs than the technology of APIs. I want to focus exclusively on getting our enterprise house in order when it comes to simple, ubiquitous, and flexible HTTP APIs and Webhooks. I strongly believe that enterprises should possess highly functional API supply chains, factory floors, and distribution channels for the fundamentals aspects of the digital economy. You have to be able to effectively and reliably deliver the digital resources, capabilities, and experiences your company is known for—-FULL STOP.
I am not dismissing that some enterprises will need GraphQL, Websockets, Kafka, GRPC, and the other API variants out there. I am just saying that 1) I will be hyper focused on just governing HTTP APIs, and 2) I will be highly suspect of enterprises heavily investing in these other areas before they have their basic API act together. I just see too many companies deploy GraphQL when nobody asked for it and teams going from zero to Kafka when Webhooks would have been just fine. Companies do this because they haven’t done the work to learn HTTP and properly equip the teams who produce APIs. I will be heavily leaning on making sure the business contract is in place before any technical contract is implemented. I will always be leading with the business of APIs, focusing on the fundamentals of the technology of APIs, and providing the policies needed to help inform and guide the people who are producing APIs—-with or without leadership involved in the conversation.
I will not just be focusing on messaging that speaks to who is making the buying decisions within the enterprise. I will have a message for them, but I will also be having conversations with and be focusing on honing a message for both API producers and consumers across the five areas I listed above. I will be working with API services providers as partners, but I will be extremely wary of their approach and their venture backed influence on what the enterprise needs. I am not looking to defend enterprise leadership buying software from the grift of Silicon Valley, but the people on the ground floor who have to live with these decisions, and have to deal with the implications of this circus. I will be looking to provide an on or off the record opportunity for conversations with these folks on my API Evangelist podcast, and I will be looking to empower them with API contract support services, helping them produce and consume APIs within the decision making of enterprise leadership and the influence of venture backed startups.
I feel like I am in a good spot. I have learned a lot working at F5 Networks, Postman, and Bloomberg in the last five years. I have some money in the bank to pay the bills for a little while, I am not burnt out, and I feel like that we are getting back on our feet after a few very difficult personal years. I feel like I still have a strong and credible voice in the industry. I really, really, really enjoy what I do. I feel like I am always learning and at the top of my game. I feel like it is time that I use my skills and my voice. I think that I also have some of the coolest domains in the API universe—-API Evangelist, API Commons, and APIs.io. I mean c’mon, I have gotta something across these domains. I’d like to do something that is real, creative, fun, and that hopefully will have lasting impact beyond just the latest investment cycle or collective market hallucination. With this moment in time, I feel like I know my shit, and enjoy a strong position within a very relevant and cross cutting aspect of our economy—-HTTP APIs.
I love writing about APIs, doing research on APIs, and having conversations with smart folks doing good work with APIs. I am going to focus here. I need to make money, but it isn’t my primary focus. I know my shit, and have a solid network of people who know me. I mean hell, even ChatGPT thinks I am something. ;-) So here I go. Putting back on the API Evangelist persona full time. I enjoy this voice. While it is not 100% my actual personality, I enjoy the hyper focus on APIs, how it is cross-cutting across almost any business sector, and the somewhat inflated ego of being the API Evangelist. While I don’t believe there is a “right way” to do APIs, I definitely think there are many wrong ways to do APIs–I want to help folks navigate these waters. I figure I have about one or two more decades of real work left in me, maybe three. I would much rather go out ranting and raving as the API Evangelist than being stuck in an enterprise somewhere. At least I get to focus on what I think matters and what interests me the most. Anyhoo, let me know how I can help—-I am really going to need y’all’s support to make this work.
