Many people call this "Enterprise architecture" and although painful tends to be worth doing.

You can think of it (simplified) as 4 steps: 1) figuring out and deciding which technologies to use for which domains and problems (these tend to be called capabilities) 2) getting rid of the ones you don't want to use 3a) enforcing use of existing, approved capabilities for new projects 3b) building out new capabilities

1) Tends to have the problem you pointed out: "it requires a greater level of technical depth in decision makers". Something that may work is to have some senior engineers in-house and embed them in the outsourced projects doing part of the real work. 2) This can be a multi-year program that needs to be separately funded. Think of it as enterprise-level technical debt. 3a) This can be the easiest part: your architecture should be part of the RFP process, with a well-defined escape hatch to 3b) 3b) Building out new capabilities needs to be i) funded separately but best ii) done as part of a real project. Otherwise you'll i) have crossed incentives with the projects as you pointed out, or ii) architecture astronauts.

HTH. There's plenty of literature on enterprise architecture, but there's no silver bullet, it's just hard work.