4. A couple of years later you want to stop an obsolete interface but you can't because a handful of systems use it and they dont have budget to change.
True this happens, but you're still better off that if you had tight coupling. In the absolute worst case you can make a shim implementation to support the obsolete use case. You can not do this when callers are directly reading your database/memory structure.
Yep, I’ve implemented new ticketing systems that have to talk to the ancient ticket system for certain things or vice versa. The ancient system had direct DB connections that had too many down/upstream dependencies and not enough budget or political backing.
Yes, but you'll at least have the API definition. And you work at the same company, so you can show up at the desks of the team responsible and demand answers. And if it breaks in production you get to page them and they have to wake up and help you! The threat of pages is a great way to coerce decent documentation. It's an important principle at Amazon that if a production service has a dependency on you, then you are also a production service. Another benefit of breaking things up into SOA is monitoring individual services. If your API is returning 500s then it's your fault and your problem (at least until you can root cause to one of your own dependencies that's returning 500s, then you can pass the buck).
1. Everyone is super excited for other teams to share their data
2. Everyone wants an exception from sharing their own data because it's too hard or too sensitive to share.
3. Eventually everything gets shared, but it takes 3-4 times longer than it really should.