In an ideal world, all of the developers on a team would be involved in the initial architecture stages of a software system. In the real world though, this doesn't necessarily work for a number of reasons including levels of experience within the team,
ego and various other motivating factors (e.g. some developers don't want to get involved, and we shouldn't force them). I talk about a "relay sport" style of architecture in my book (
https://leanpub.com/software-architecture-for-developers/read#relay-sport) where solution architects create the architectural vision and then simply hand it over to the rest of the team, like a baton in a relay race. Often, these solution architects have very little subsequent interaction with the team, effectively leaving the poor team members to implement the vision on their own. This is bad. My recommendation is to avoid this wherever possible, and either get the architect coding (or at least being a part of the ongoing team) or getting one or more of the developers to assist with the architecture stuff. Many teams talk about pair programming, so why not pair architecting?
To pick up your other point about decisions, I truly believe that every developer should understand the architecture decisions being made, and this includes the rationale behind them. For example, if you're using a particular
pattern or technology on your project, understanding *why* can help considerably, helping to create a much more collaborative environment.