Sounds healthy to me. I've definitely seen it work. Saying "no" to people who want changes in Service B can be the right thing for the future health of the entire company. E.g.
Service B: We built a distributed storage system. You can append to files, and you can read at a given position from finalized files, and that's it.
Product A: We'd rather have an ACID database.
Service B: lol, fuck off.
Product A: reads some distributed systems papers, improves their design OK, we now realize that these primitive operations are sufficient.
in large companies most of the times its not as simple as that, lets say Service A uses data exposed by Service B. Now Service A wants to add few more data to Service B's response, however Service B is not interested in adding that as it's not in their priority list. Now Service A is stuck waiting for Service B to provide that. It happens at scale as well. That's one reason enterprise analysts spend hours on phone. As their system is dependent on multiple other systems from other departments. Navigating that at scale is tough.
There’s nothing technical about that, though. If there’s some data that a product needs which can only be produced by another team with an interface that does not yet exist, the alignment has to be at the executive level. Either the product with the need gets engineering resources from the other service, or it doesn’t launch.
My philosophy here is informed by regular attendance for years at the gmail SRE design review, where typically some guy from Search would come around and say something dumb like "send us every message for universal indexing" and gmail leadership would say "LOL no. fuck off." Then a few months later they'd come back with something better like "compute for us these privacy-protecting index fingerprints for universal search" at which point you can start to say yes. I don't see the value in immediately capitulating to what other service owners claim to need, especially when your first allegiance has to be to your own userbase.
of course yes in product companies or tech companies that can happen. in large banks for e.g. its more difficult, as different departments are run pretty much like different companies. you can eventually align things either at peer level or from executive level but would take lot of time. its not a problem of SOA per se, but overall friction/inertia inherent in large orgs..
Service B: We built a distributed storage system. You can append to files, and you can read at a given position from finalized files, and that's it.
Product A: We'd rather have an ACID database.
Service B: lol, fuck off.
Product A: reads some distributed systems papers, improves their design OK, we now realize that these primitive operations are sufficient.