How often do you see your architecture changing? Will your team religiously update the document with each refactor/new feature? Will the document last the lifetime of the project? How big is your team? Who is the audience? To what detail do you want to document?
In my experience, a team's formal architectural documents tend to fall by the wayside very quickly. When everyone on the team knows each other and the team is small, I tend to avoid these documents. They get out of date and lead new developers astray. Documents are eeevil. A solid team that openly communicates with each other trumps formal architecture docs any day.
At some point such person-to-person communication cannot scale. You must now correctly chose the level of eeevil documentation that applies to the size and scope of your project. Remember too much formality will mean changing the documents becomes too cumbersome. So much detail may be documented that maintaining the documents becomes onerous. You get out of date docs that stay out of date too long. Too little formality means that the team in Seatle has no idea what's going on.
Medium sized teams could do well with just a wiki. Very large teams may wish to have full-time documentation staff that assist in maintaining extremely formal documentation. At this point, documentation should be more than a convenience and the team should make it mandatory.