It is not a secret that user involvement increase the success rates of software projects. We can basically look at the architecture as a mini-project inside a project. The users in that case (as my entry on Stakeholders shows (or tries to)) are the stakeholder.

Richard Demers talks about Architecture Control Board (on his smalltalk blog - oh my :) ) as a way to increase the involvement and of stakeholders for large software projects. The idea is to engage as many stakeholders groups as possible on a periodical basis and to set up a review and change board that approves changes in requirement and also review and approve  the architecture (I'll talk more about something similar when I'll get to E - Evaluation in SPAMMED).

Richard lists 13 points in regard to the Architecture Control Board - the most important ones (in my opinion) are

• the ACB set the requirements scope for the architecture (what requirement/quality attributes should be accounted for)
• the ACB  review and criticize the architecture - they don't, however, design it or vote for its correctness.
• the architecture team has final say on architectural decisions (though an escalation path to upper management should exist)
• the documentation approved by the ACB is the ultimate deliverable of the architecture team (i.e. the "Software Architecture Document")
• go read the rest :)

While establishing a "formal" ACB in smaller-scale projects is probably an overkill you may still want to follow some of these tactics on a less formal basis to increase your stakeholders involvement and more importantly cooperation.