Weekly API Evangelist Governance (Guidance)
Let’s give a big Monday shout out to our SDK partner APIMATIC. API Evangelist storytelling occurs because of APIMATIC, and I am thankful to have their support for this ride!
There was no storytelling this week aside from the announcement on Monday that I was joining up with Jerome Louvel to build a new startup called Naftiko—which will be focused on modernizing API integrations. With this announcement I am putting all my energy into market research for our products. This doesn’t mean that API Evangelist will cease. As with other shifts over the years, you’ll have to just give me some grace as I find my new rhythm.
As part of my shift towards Naftiko I am studying the approach of API integration providers as well as the new breed of API consumption providers. It is interesting to shift my perspective back from the API producer view towards the API consumer view of things. I firmly believe that the majority of the power when it comes to APIs lies in the hands of the API consumer, but the majority of discussion occurs around producing APIs because of who historically gets sold to within the enterprise.
To help guide my API market research, here are the six areas I am focused on when it comes to APIs right now…
While API discovery has always been a speciality of mine for years, I want to step back once again and think about the realities of finding APIs, abandoning the notion that there are many people who actually care about finding APIs, and think about what people are actually needing to find. Are they looking for new business capabilities, or maybe looking to maximize the capabilities of the software they are already using. ProgrammableWeb, and other long gone API discovery solutions demonstrate there isn’t money in API discovery alone, but with all of the APIs available to us, as well as the ones already in use that we don’t see, there is a growing urgency to “discover” APIs, it just isn’t the ideal scenario we envision it to be, and is something more about discovery to accomplish specific business outcomes in any given moment we find ourselves in.
How and why we integrate with our APIs represents a broad spectrum of our reality. You may be integrating into an application, but you are also likely integrating into another system. Integration involves onboarding and learning that goes into putting a new API to work, or expanding the usage of an existing API. API integration often involves finding an SDK, or writing custom code, but could also mean the usage of low-code or no-code solutions. API integration can happen locally, on-premise, or in the cloud. API integration is predominantly using HTTP as a transport today, but could also be using TCP, and direct database connections still fit into the API integration play book in my experience. The question I have is why is API integration still so cumbersome and difficult, and what would truly simplify that for engineers?
A significant piece of the integration and onboarding process with API is authentication. However, API authentication is also an ongoing aspect of API security, and something you need to handle properly during integration, but then also during the life of the integration. Managing our tokens and other secrets, turning them over with time, and confidently applying them across multiple APIs used by integrations is challenging at scale. Understanding and onboarding with authentication is often associated with API integration, but I am more interested in how authentication is managed over time, made more observable, and of course kept secure. While there will be a lot more to think about when it comes to security, such as encryption I feel like there is a huge amount of low hanging fruit when it comes to abstracting away the complexity of authentication.
Moving further into the territory of when you properly integrated with an API, I am studying API consumption. This is flipping the narrative from what API producers should be thinking about when it comes to API service composition, to what an API consumer cares about when they are consuming an API, or multiple APIs. I am keenly interested in what developers think about, but also what their managers and other stakeholders are concerned with. Cost management seems to be the top concern based upon what other service providers are focusing on, but I am guessing there are other concerns present, especially across many different APIs. API consumption is where I think API consumers hold most of their power, and I think when looked at in aggregate we are going to paint entirely new pictures of what API usage looks like in the future.
The dominant conversation when it comes to API automation right now is around artificial intelligence and agents, however the dominant form of API automation in usage is not AI, and reflects a pretty classic approaches to ETL, iPaaS, and other ways of approaching automation. I am not dismissing agentic approaches, but I am interested in having real world business conversations about why the agentic approach is needed over other existing approaches, and what the nuance of discovery, integration, authentication, and consumption looks like from a technical perspective. With joining Naftiko I am zooming back out again beyond just HTTP and considering event-driven, CI/CD, CRON, and other ways in which we automate things and keep the bits moving via APIs across many systems.
Ultimately I think focusing on API capabilities that speak to what is needed from a business perspective over the technical details of discovery, integration, authentication, or consumption which will ultimately have the greatest impact. After a week of deep dive into existing iPaaS and other integration solutions I can say they are still very technically focused and speaking to an engineering audience. While this is still needed, I also know that we need to continue shifting things towards being something business people can understand and put to work. Business alignment of API integrations brings in a wider variety of stakeholders, but also will help ensure we aren’t “complexifying” things just for the sake of technology, which is commonplace when engineering are left to our own devices when integrating with APIs.
This is just a little sampling of the market research I have in motion, and the storytelling I have planned for the coming weeks and months. If you are an API consumers, I’d love to hear from you. I will be interviewing folks throughout June and July, and working with companies to flesh out what an API discovery, integration, and consumption strategy might look like for their business. Naftiko will have an open-source tooling and artifact core, with a sensible commercial layer over the top. I am looking for folks who want to tackle the problem of API consumption across many APIs that are used throughout a business by many different teams. While producing APIs is still top of mind for many businesses, the API sprawl doesn’t just mean the APIs you produce, and getting a handle on our API consumption is quick becoming a top priority.
Thanks for tuning in while I shift things (again). I’ll get the blog active and aligned with the market research I am doing, and I’ll keep the drum going with this weekly newsletter. It is just taking me a bit to switch gears, and get the momentum back up to expected levels. I am definitely feeling energized. Mostly because I have a partner in crime who is crazy smart and driven to build high quality tools and services-—someone I can bounce ideas back and forth with. After that, I am enjoying the focus on the consumption side of things, as I think this is where we need to be doing the most work right now. So, I am eager to be deep diving on the consumer side of things, which is where I think the rubber meets the road, and where we have the most work to be done when it comes to taming the API sprawl that is all across our business operations.
You cannot control your own population by force, but it can be distracted by consumption. - Noam Chomsky
If you need API Evangelist to help out with API governance please let us know how we can help. And thank you again to APIMATIC for their continued support. If you have any questions or would like participate in my market research and conversations, please feel free to drop me an email today.