I as I have said before, if were to have my time over as a product leader again, I would have been more assertive and downright belligerent about making sure that APIs were absolutely central to product design, and that no code would ship without a properly discoverable, documented, performant, secure, read and write API. No matter how many RHINOs are at the door.
I’m not a big fan of having different standards and qualities for internal APIs and external APIs. What is an internal API one day, is maybe an external API another day. I’d also insist that APIs are built not just for the user facing or UX layers of the product but for all layers of the product. If someone wants to build their own UX cos they don’t like mine, have at it. If you need to inject a different machine learning engine than I have, go for it. If the workflow needs to head off into someone else’s application for a while, great. (I don’t want to how granular microservices should be here, I’ll leave that to another day, or even better to someone else).
Photo via https://www.wikiart.org/en/edward-weston/onion-halved-1930
The market choses at which layer of the onion you operate.
This becomes even more important with cloud applications. For instance, the speed of innovation in monitoring and observability tooling is dramatic. The more you can open all the layers of your application to these sort of tools, the more reliable and performant your applications will be.
For vendors and users that have a massive portfolio, driving API discoverability and consistency is really challenging. Shifting to an API first approach once you have built a product is hard. It is akin to relaying a pipe under a road that is already macadamized. But the longer you leave it, the worse it will get.
Tools to help manage APIs will only become more critical. We will see more software business that are not just API first, but API only. I’m monitoring a few in the payroll space, for instance.
Over the last few months, I have done a lot of due diligence work for investors (PE,VC, and Corporate). I ask lots of questions about APIs, as much as a window into the organization’s development and product culture as anything else. I think asking product leaders to describe their favourite API will become my new favourite question. I’ll also make sure that we ask customers and partners the same thing too. If you are buying software, spend more time asking about APIs than you do about UX. Same if you are interviewing…..
