How do you ensure that the project will be build with "good" design decisions enabling a flexible software architecture?
How do you balance between completely leaving the architecture to the teams on one side, and let all architecture control to a few individuals on the other side?
Do you have an "architecture group", "architecture label" or things like that?
I could explain how I would do it, but this says it better than I could.
I handle this by doing some planning up front -- generally, I have some prior experience with a similar application to help with this. If not, I'll do some exploration in the space to get an idea. Once a basic architecture is laid out, I'll start developing with it in mind based on my prioritized stories. Then, I refactor as I go along to address shortcomings or errors in the architecture.
In my experience, the best way you do this is have experienced developers / architects working on the projects that drive the architecture vision on a day by day basis.
I would suggest its up to the dev lead on the project to control the architecture and to ensure that all new work fits in with it.
A prerequisite for Agile approaches is an architecture you already know how to use.
If the architecture is not well-defined and completely understood, you can't really take an Agile approach.
You need to have some technical spikes that show how the architecture works, and how the various pieces will fit together. You can do these are preliminary sprints, but they won't lead directly to a release to users. They're a special case, required to get to an architecture you can use.
Once you're past this "understand the architecture" effort, you can then start to execute sprints that lead directly to releases for the users.
Without doing big design up-front, there is usually a basic design that applies to the each project. Usually, this defines basic layers to respect in the design of the application. Most other design decisions are made by each developer.
Our development process is based on short development bursts with frequent peer review. The quality of each developer's architecture decision is validated at peer-review time. This also includes validating that the code follows the product architecture.
Depending on the type of project and the tools that are available, we also use tools like macker to automatically validate the integrity of the layer-cake.
I would also recomend reading fowlers document Is Design Dead, as far as I understand his arguments if you consider all the agile practices as a whole then you gain the freedom to make large changes and so can evolve an architecture.
Refactoring works most effectivly with continuous interation, testing is enhanced with TDD and continuous integration ... I could go on. Evolving 'architectures' are only limited if you are unable to make the large changes requied to correct 'mistakes'.
Additionally, I think you have an architect as a stakeholder in the project, they contribute user stories which are in turn delivered back to the architect.
This is also a good way to utilise pair programming with the architect working as part of the pair. In this context the architect is not so much a dedicated person more a hat that a member of the development team wears while pair programming.
I think XP does not diminish the role of the architect (and architecture) it just places the resonsibility on all team members to deliver and spreads the cost over the lifetime of the project.
[edit]
Per other comments dont be afraid of some upfront planning, itteration zero is a good time to try and chart a bit of a plan, just dont get to strict about delivering it to a specific time scale.