In many cases, an API-centric strategy is a sign of the strategists not wanting to have to deal with actual end users and their needs. It’s much easier to create re-usable services that someone else has to assemble, and even easier to create a meta-strategy for that.

(On the plus side, an API-first strategy works great if you have an API gateway product to sell, or want to legitimize legacy systems that are slowing you down by putting a “bi-modal” or “two-speed IT” sticker on them)

I blame most of the disasters in modern enterprise IT strategy on the fact that it’s people like me – backend architects with way too little focus on UI/UX aspects – who have been put at the controls for far too long.

You need a strategy for modular application delivery, not only including, but starting from, end-user needs. APIs are a meaningful means to an end for that. Starting with them is going to end badly, independently from your choice of protocol or data format.

Why default to having an API?

Doesn't - at the end of the day - everything in enterprise IT have an API? Intentional and planned, or alternatively just as a workaround to get at some critical piece of data. Direct-to-DB access from foreign systems in the worst case.

For ISVs, I think it's even more important: if you provide APIs, you allow far deeper integration with other systems, providing higher value to your client (and of course making it harder for an customer to replace your system as it's now an intrinsic part of processes).

In our company, we run 100% on various SaaSes. We always pick solutions which have APIs over ones which don't, because they allow us to customize processes, connect with our other systems and replicate our data (R/O for reporting). SaaS without APIs would be too risky for us.