With his latest post API Complexity Is a Lie, How some businesses live off API complexity while others sell simplicity, Bruno Pedro nails a reality that perpetually weighs on me daily as part of my work. It is easy to be excited by the latest API hype cycle when you live in the forest, but when you regularly head up to the rocky outcropping above the forest and sit thinking as I have for almost 15 years, it becomes much harder to get excited. After a while you realize why we are still so bad at the fundamentals of HTTP APIs like paths, parameters, status codes, and the security of our APIs-—it is by design. We are told that new technology and more venture capital will be the solution to all of our complex enterprise problems, but what if it was the opposite, and as Bruno highlights we are just being played by the reality that “businesses thrive on incentivizing the growth of API complexity.”
Startups are trained and designed to find a pain point you have, and provide a solution for you. Then bundle and bake that solution into packages and tiers you may or may not need. I hate to generalize like this because I know of many startups who don’t do this, but the majority do. Or the majority will eventually, as they mature and investors are looking for an exit. I don’t do this to throw shade, rant, and disparage startups. There are many startups I believe in and have believed in over the years. And, I will continue to find the energy and enthusiasm to showcase the useful solutions out there. I write this to ensure that you have a sensible vendor strategy in place as an enterprise. I want you to realize where a lot of your technical debt and complexity comes from. I get it, you probably didn’t make all the decisions to buy into a 3-year contract with your API management solution, or the 5-year contract with your API testing solution. I just encourage you to take inventory, and begin crafting an API vendor strategy to help mitigate complexity and minimize the crazy making that occurs intentionally as part of your API operations.
I was a part-time ringmaster and full-time clown in the API management circus from 2010 through 2016. I’ve had a piece of the action in this circus as well as much of the “unbundling” hustle that occured in the park lot of this circus as it is being dismantled to move to the next unsuspecting township. It is a theater. Complexity theater, with smaller stages for security, design, testing, and other complexity hustles. I can join you for a game of street dice combined with fire eating along almost any stop along the API lifecycle, but the difference with me (and Bruno) is that I can actually do what I am talking about. I can get down at the tactical level and work side by side with you to do APIs, and I can get in the elevator and sit down and craft the strategy, program, and platform with you. I like making money, and I like telling stories. I also like contributing to a less complex world, and leaving things better than I found them. I also like being honest and straightforward. Some might say that I am “too passionate”-—I can’t help it. I don’t know of any other way of being.
I like Bruno’s focus on API documentation as a visual representation of the simplicity or complexity that exists within an organization publishing APIs. Your portal and documentation, as well as the APIs you publish are very much an externalized representation of what is going on in the head of your enterprise. It represents all the good and bad decisions you’ve (as an enterprise) made over the years. The simplicity and usefulness of your API documentation represents a cumulative and collective ability of your enterprise to externalize and evolve a digital resource and capability. The words, structure, flow, and coherency of your API documentation reflects not just your internal ability to to publish an API, but to tame, or at least harness your internal API complexity and will speak to your ability to tame, harness, or even lead within your industry. API documentation is so much more than just API documentation. There is a reason API documentation is the number one pain point for API developers. Your API documentation tells a wealth of stories, it all just really comes down to whether or not you are the one in control over that narrative, or you’ve outsourced your enterprise narrative to your vendors.
I have to attribute the phrase “why we can’t have nice things” that I used for the title of this post to my ex-wife, and mother of my kiddo. She used to say this whenever I’d make some insane decision to do yet another startup back in the early parts of the century. I had just found some stability in our lives and I would get some delusional inspiration to build a new API-driven something or other, rather than focus on my core business offering — which was called Original Web Solutions (API powered websites). I have no regrets as it has all led me to this moment in time, but has left me with an ongoing superpower in assessing why “we can’t have nice things”. ;-) The next wave of API Evangelist is 100% focused on taming, harnessing, and resisting the API complexity that exists across our API operations. I laugh at myself saying this because my own approach and pitch right now is still very, well..complex, but I am doing the hard work to distill it down into something that will make sense to leadership, business, and engineering stakeholders. I am doing the hard work to allow it to work with bedrock API infrastructure as well as the latest offerings in Gartner’s API hype cycle. I realize that I am not going to change people’s behavior overnight and that there will be plenty of folks I can’t reach–however, for those who wish to stay sane amidst all the complexity Bruno, and I are here to help you make sense of things.
