One thing that I have found from working on a few projects is the value of an architecture on a page diagram. A representation of the architecture that is abstract enough that a non-technical people e.g. Project Manager, Business. They need to be able to understand the components on it and the important bits, to be able to use it as a reference point when having a discussion. The diagram should also be accurate enough that you can use it when talking to technical people about technical details of the architecture e.g. Security, Infrastructure, Asset SMEs etc.
Unfortunately it isn’t something you can just create, these diagrams seem to evolve so I recommend that once you have attended enough discovery workshops and have a good grasp of the scope knock up a diagram of the proposed architecture and socialise it. Don’t be attached to the diagram it will most likely need to be changed based on feedback or it might need to be totally redrawn because people can’t connect with it. Let it evolve and you will know you have got it right when you see other people in the project with a tattered copy of the diagram with writing all over it and a coffee stain or two.
One of the biggest problems that occurs when evolving your architecture is miscommunications. When discussing an architecture it isn’t uncommon to spend half an hour or more talking about part of the architecture only to realise you were talking about two completely different parts of the design. A diagram allows you to have a common point of reference, something people can talk to and say “There is a firewall between that system and that system”.
Along the same lines when talking through constraints and the like with the business to explain a cost component etc the diagram allow you to better explain things. I am not sure if it means the person you are explaining it to better understands what you have explained but I think the value is that they can then point to their copy of the diagram and explain the constraint to someone else.
Hopefully doing this you will be able to better manage your stakeholders technical and not and end up with an architecture that is well understood so therefore gets through the necessary governance with little trouble.