Academic or Street API Tooling
07 Jan 2020
There always seems like there are two separate types of tools in my world, the academic tools that consider the big picture and promise to steer me in the right direction, and then there is the street tooling that helps me get my work done on a day to day basis. After going to work for a street tooling vendor who has some academic tooling aspirations, it has gotten me thinking more about the tools I depend on, and learning more about what people are using within the enterprise to get their work done each day.
I have used different academic tooling over my life as the API Evangelist. I’d say every API management tool I’ve adopted has been very academic until recently. From my view API management started as academic and then became a factory floor commodity. I feel say Kong and Tyk are the only version that have achieved a street level status within all of this, and NGINX is looking to turn it’s street cred into more of something that is more academic, and visionary. There aren’t many academic API tooling that have gone from vision to implementation—they just can’t survive the investment and acquisition cycles that gobble them. Making it difficult to see the real adoption they need to become baked into our daily lives. API management has done it, but very few other stops along the API life cycle have realized this level of adoption.
Street tooling, or the hand tools developers use to get their jobs done on a daily basis are a much different beast. Postman and NGINX are both examples of tools that developers know about and depend on to operate each day. Using NGINX to deploy and Postman to consume APIs each day. These aren’t tools that promise some grand vision of how we could or should be, these are tools about dealing with what is right in front of us. These are tools that keep things manageable, and operating each day. They are the tools that allow us to do what we do, make sense of the fast moving digital gears around us, and reliably delivering the resources that we are expected to deliver.
I am not passing judgement on the value of academic over street tooling here. I am simply acknowledging that there is a difference between what is already in motion across the enterprise, and what you'd like to be in motion. I think you can consciously develop a street API tool, but I think it is very hard to actually realize at scale. I think we always lean towards the future, rather than designing tooling for what we need now. This is one of the dangers of always looking towards the future and thinking about what is next. Sure, thinking strategically is important, but ultimately it is the tools that make a difference in our day that will see the adoption street tools enjoy. The other very challenging aspect of street tools is the business model isn’t always clear—it is the academic vision of what will be that strategically grabs enough attention to warrant dropping the money needed to move things forward.