What should every software engineer know about software architecture?
In the short term, dictating an architecture is faster and may even be cheaper. However, in the long run, we build better teams by letting them think for themselves, letting them evolve the architecture, and sometimes letting them make their own mistakes. When we focus on the team, they get better with time. Execution is much easier as architecture is the team's ideas in the first place.
Architecture reviews, however, have their pitfalls also. Paul (@pzfreo) used to call this fly by architecture where Architects walk in, listen, give comments, and move on. As an architect, It is easier to look, complain, and take the design apart. If you are not careful, you might leave the team bewildered and not sure what is the right thing to do.
We address this problem by having a list of shared architecture principals. Those are principles that everyone agrees. Architects give feedback by saying this is not good due to principal X. Principles guides us and keeps our discussions rooted. They also avoid philosophical battles that go on forever. Finally, if the designer has never heard of the Principle, it is easy for him to learn.