2. Draw a path between from the entry point to each business goal (end point). This needs to be in writing.
3. Identify intersections and overlaps.
4. Forget everything about code style, popularity, and technical capabilities. Those are barriers to the business goals from the developers. As the leader set the standard for execution. At this point the nature of the work should be clear from your prior planning. Directness and simplicity* should be your only primary guiding principles.
5. Refactor as necessary during execution to eliminate complexity and any deviation from the minimal achievable access (direct path) to the business goal.
* simplicity - That word means fewer not easier. If you want easy then don’t be an architect.
I think it depends a lot on what the software is and what the industry is. You could leverage reports from consulting groups (I can't remember the name of the big one, maybe McKinsey). As someone else mentioned, gathering input from employees can be a good data point to have too.
I think by looking at software and industry trends you can come up with some ideas about what you want to do. Then I would bounce those ideas off of people you trust who are knowledgeable in your industry or company.
Many companies are moving to, or already in, the cloud to some extent. DevOps and DevSecOps are pretty popular. Site Reliability Engineers (SRE) and the associated concepts/tech are also on the rise, such as automated testing. Machine learning is starting to take off, but I'm not sure it's right for all companies (smaller companies might be better suited to buy rather than build).
If the latter means finding people who have talents that work well together, and ensuring they have focused-time and access-to-people they need.
Note that there is a difference between saying "we should do this!" a bunch and actually allocating resources to do it. America didn't land on the moon because of Kennedy's speech at Rice University. America landed on the moon because of bills that got passed in appropriations.
> lost the bigger vision
Your leadership team might not be repeating themselves enough. Good leadership often means repeating the things that matter.
I’m not clear on if you are purely looking at architecture or also product features, etc. Your strategy would need to fit into all of that too.
The plan is long term so it’s ok to take some time over it. Ask lots of questions to different stake holders to get a good picture of the problem you are trying to solve.