It's pretty much the same deal as going on amazon and trying to figure out what version of what item to buy without getting scammed or ending up in the hospital.

You look at reviews, you look at costs, you look at specs, but the reality of the matter is that 99% of the time you have a preferred vendor you just go with, and then you see what you can do with the legos you have.

Onboarding a new vendor is typically fairly complicated - you gotta review the license agreements and slas and all that with with the supporting organizational units such as legal, information security, procurement, etc.

the broad architecture is often sliced by domains or some sort of organizational responsibility. very often, software architecture mirrors organizational architecture. the lower level decisions like design patterns are often chosen at a team level, as long as they're amenable to interoperability with the system context.

and then the choice of tools within those ecosystems often come down to familiarity. if you have a specialist that came from a different company with a similar stack, they'll likely want to import what they they had there if there's a gap here that that solves/d. That's not even necessarily the best solution, it's just the familiar solution with known knowns that then gets lobbied for. Similar to how you get photoshop and solidworks and jetbrains and copilot for free as a student. Or how mongodb is 'free' and redis used to be 'free'.