earlier replies
Replying to @ingorammer @stilkov @djgummikuh
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
Stefan Tilkov @stilkov
15 Apr 2020
Replying to @stilkov
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
So I'd argue that, for a SaaS-Provider, an API *is* a critical component of your software. For Enterprise-internal developments, it might be different, but I'm always a bit afraid of ODBC/JDBC as the final other API, if the team itself doesn't provide one.
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”
1
1
I think that we agree on nearly all - or maybe 100% of all - points, actually. For enterprise-software, API-on-demand (at a possibly later time, when you know what the other side of the API needs them for) instead of API-first is quite likely the best approach.
2
I am not convinced API-first (especially in enterpise IT) always refers to designing the API before the first line of code for the actual service is written. It can very well refer to designing an API facade in front of a long standing legacy data source/application.
1
Absolutely. And it is better to define the API upront and at least strive to make it a little bit abstract and reusable, instead of creating the Nth point-to-point fat integration in the ESB for the same data. Real life in corporate IT is not always beautiful.
1
Replying to @stankov @djgummikuh @ingorammer
Please do not read any love for ESBs or business logic in integration platforms into anything I wrote :)

Apr 15, 2020 · 11:13 AM UTC

1
2
Replying to @stilkov @djgummikuh @ingorammer
As a long term follower of your work, no danger of that. :) But this context is important. I have a much bigger problem with "API as a product" -> it is absolutely impossible to have a (trained and capable) product owner for each API in the enterprise. Esp. internal ones.
1