I am neck deep in market research for Naftiko this week, and it is very strange for me to have a wealth of information I want to share with you, but I am also looking to apply some thoughtful control over my storytelling to support the upcoming work on open source specifications and tooling—with a commercial fabric surrounding it. I am spending all my daily cycles on Naftiko, but I figured I can keep the API Evangelist heart beat going with a single narrative here in the newsletter until I get through this work.
Tea Leaves
As part of market research this last week and last I have been thinking deeply about 25 integration service providers and the 100 APIs they integrate with. As I’ve done for 15 years I profiled what they are offering. The marketing. The documentation. The APIs. I find that reading the API tea leaves always requires understanding things at those three layers. The marketing is always least precise, with documentation getting more precise, but with many API providers, you have to actually use the API before you get the full picture. If you can’t access the API, it is unlikely you will actually fully understand what is going on with any startup selling their warez in the API economy.
Storytelling
I like telling stories. I see the value of telling fictional and non-fictional stories. I also have a strong understanding of sales, marketing, and developer relations. I am a storyteller, and I get the value of bending the truth and believing in what you do, and relying on this to see the world you want. I have always been fascinated with this line in the tech sector, and I am determined to always walk a line where I can achieve my business objectives without selling my soul to the market. When I look out across the marketing, documentation, and APIs powering the business narrative right now, there isn’t a lot of precision and structure to what is being offered, which makes it very hard to make your way through the sprawl and chaos without losing your way. It is easy to see how folks get lost in what is being offered today.
Always Cloudy
Don’t get me wrong. The API space has always been cloudy. The modern notion of APIs was nurtured in the precise technically, but imprecise from a business perspective, concept of the "cloud”. I learned to tell stories about APIs in the clouds. You needed a certain level of imprecision to get business people on board, but you actually needed more precision when it came to the technical details. However, along the way I think the business folks involved in the venture capital side of things have lost their mooring when it comes to the technical details that matter and are just doubling down on the cloudy details of crypto and intelligence. You see this taking hold of the majority of the 25 integration service providers and the 100 API providers I profiled over the last couple of weeks—there is a kind of purposeful obfuscation and suspending of reality that worries me.
Suspending Reality
I am a big fan of transit systems as a visual representations of API infrastructure. I’ve written a lot of stories and done a lot of talks about Harry Beck’s original subway map for the London Underground—which has become the visual standard for communicating all large transit systems in the world.
Harry admitted that part of the secret to the approach was suspending reality to help onboard your average everyday user with the complex system. Your average public transit rider doesn’t need to know all the details of the system, they just need to make their way around the system. The visual representation of the system needed to be rooted in reality, but not too rooted in reality. You can see this being negotiated over the last 100 years of the New York City Metro—a system that is relevant to me and millions of others. This original NYC map followed Harry Beck’s approach in the design of the original and now icon NYC subway map. During the 1940s and 1950s as NYC asserted control over the system the Hagstrom’s map was the dominate way of visually represented the increasingly complex NYC Metro.
Over the years other attempts were made to visually represent the complex NYC system, putting a lot of detail into the map that would help people find their way in a more precise way, and what some would consider overloading the map with too many technical details as here in the 1960s.
Then in the 1970s a new approach to telling the story of the NYC metro was commissioned with the Vignelli map which sought to make things more attractive and readable. Resulting in a much more abstracted and imprecise map of NYC that was visually pleasing and considered artistic by many.
While attractive and pleasing to many, most found the map to not be useful and practical. It just did not make sense to may ultimately evolving in the 1990s towards something that was much more of a blend between the artistic and utilitarian approach.
However, this year, the MTA has moved the needle back towards a Vignelli map style, opting to suspend reality even more. Look at the shape of Central Park to get an idea for how condensed reality is to help make the map visually helpful to everyone.
OK Kin, what does this have to do with APIs? Well, the negotiation around the NYC subway map represents what I think is the overall negotiation we are having around APIs right now. Which seems nerdy and specialized, but with APIs impacting almost every aspect of our personal and professional lives, I feel we need to agree upon how much reality is acceptable to suspend when it comes to talking about the system underlying our world.
Precision
One of the things I notice across the integration and API service providers I have been profiling is what feels like a lack of precision. This has always been present when it comes to the API space, but the volume seems REALLY, REALLY LOUD RIGHT NOW! The number of sites which took me longer than normal to understand what it is they offered, or leaving me unable to actually figure it out without talking to them was pretty high. This is where I feel like a little more precision is needed to help us understand what is just talk versus what is really possible when it comes to integration, consuming, and automating with APIs.
Reality
I think there are times where the suspension of reality is acceptable and times where it isn’t. I feel like the fact that people tend to be operating in isolation is being taken advantage of when it comes to framing what reality is or will be. When it comes to the business and technology of APIs you have to separate between whose business and technology it is—the entity selling or buying the technology. This is why I think APIs go along way towards grounding things in reality, being the more precise story over the documentation, and especially the marketing of companies. I think the balance we seek with technology lies in the negotiation between producer and consumer at the API integration layer.
Business
Ultimately it is the business of APIs that needs the most alignment in the negotiation that is happening at the integration layer. I just don’t believe the cost, monetization, and revenue elements of each API integration is part of negotiation at the individual integration level as well as the overall domain or industry those integrations are serving. I think the feedback loop with the business and technical of people buying integration and API services, is out of whack with the business and technical of people selling integration and API services. I don’t think there are enough technical details present in business conversations, and I don’t think there are enough business details present in the technical conversations. This allows for a suspension of reality which isn’t always beneficial to those who are on the ground just trying to make their way around these complex systems we live in these days.
Balance
In the end, I think cycles swing back one way or another when it comes to how we approach complex things. I don’t think there are easy answers here, and too much technical details isn’t sustainable for the masses and unrealistic or unusable approaches to navigating the world of technology. Things are out of balance in the API layer of our world right now. There is a lot of hustle and snake oil out there, and a lot of suspending of reality in hopes you can make the “line go up” in whatever it is you are doing. I feel like we have to convince as many people as we can to look beyond the line just going up for this quarter or the next, and consider how the line going up in more longer term ways can help bring some of the balance we need. Which I think the controls for are present in each of the individual integrations we depend on to do business each day.
I am not sure when things will start balancing out, but after spending some time profiling the stories that companies are telling about what they offer, I can tell the time to balance things out it is coming soon. I am not sure how fast the pendulum will swing back the other direction, but it is coming. I think we will need have a more precise vocabulary when it comes to what our applications are doing with data and other resources. I think we will need to have more alignment with the business of integrations, helping us account for why an integration exists, what it costs, and what value the integration is doing. I think these discussions at the integration level, but also team, domain, and wider organization level—answering the question on what the ROI is on all of this API sprawl. I think once the fog clears even just a little bit, we’ll need to do some accounting to justify how we got here, settle up our books a bit, and have some conversation regarding where we want to go next.
“The corporation is supposed to take us outside ourselves. We design these organized bodies to respond to the market, face foursquare into the world. But things tend to drift dimly inward. Gossip, rumor, promotions, personalities, it’s only natural, isn’t it—all the human lapses that take up space in the company soul. But the world persists, the world heals in a way. You feel the contact points around you, the caress of linked grids that give you a sense of order and command.” ― Don DeLillo, Underworld
