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.
13
27
2
81
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.
1
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).
2
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.
1
Agreed, see nitter.vloup.ch/stilkov/status/1… – that’s not what I’m criticizing
Unless APIs are the actual product you provide to your outside customers, the horizontal divide created by putting an API boundary between your end users and the business logic (and the resulting Conway’s law effects) will create lots of pain and little value.
1
1
Ok, but where is the boundary? Most customers of the SaaSes we use quite likely don't care about the API, only about the GUI-level functionality + hidden backend. For me on the other hand, they are one of the most critical features.
1
I was explicitly not talking about SaaS. I’m fact, you could probably sum up a lot of my critique as “your legacy enterprise backend is not a SaaS product”
Apr 15, 2020 · 10:39 AM UTC
1
1