API Service Providers Need To Decouple The Services They Offer To API Providers

As I work with each generation of API service providers, I always notice a portion of them that are born out of a previous era of software development from the 1990s, and even sometimes the early 2000s, This reminder frequently brings up the point of how these companies need to follow the same advice they (we) offer to their own customers--decouple your resources, into small API driven services. I regularly stumble upon companies who asks me to review software services that are targeting API providers, that don't reflect an API-first approach.

My advice to these companies is always to step back, take a deep breath, and consider how you can embark on the same journey that the companies you are targeting have already begun traveling. Define all of your digital assets, break them down into the smallest possible API resource you can, then retool how you sell these service through an API platform, as well as web, mobile, and other micro tooling that you, and your partners can build on top of these APIs. To me, this is the Dogfood (Champagne -- @inadarei) 2.0 conversation that needs happen in order for the API space to mature to the next level.

In 2015, if you are a company that is selling a service to API providers of any shape and size, and this service is not available via an API, and offers a self-service on-boarding flow, I probably won't be talking about it often. I won't be spending too much time convincing API service providers that they need to reduce this friction--it seems like common sense at this point, I will be focusing on the leading service providers, that they need to be "communicating" using common API definition formats like Swagger, API Blueprint, and with Postman Collections.

Just like we tell companies that are considering the API journey, "don't get left behind", as an API service provider you need to make sure and decouple your services, making them more agile, nimble, and scalable. Sound familiar ?? ;-)