I really like that you’re encouraging (agile) architects to document alternatives considered but ruled out and why. This may seem counter to the agile philosophy of minimalist documentation–there is pushback on documenting at all, so it’d be reasonable to ask why we should document approaches we decided against. But it is not counter to _being_ agile. It’s not agile to revisit/rehash decisions, simply because… the collective “we” forgot, someone new came into the room, etc.

Jeff Tyree and Art Ackerman’s “Architecture Decisions: Demystifying Architecture” http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/so/&toc=comp/mags/so/2005/02/s2toc.xml&DOI=10.1109/MS.2005.27 also calls for documenting alternatives not chosen.

Anshu Gaind has an architecture decision template that I also like because it explicitly identifies drawbacks of the approach, so that the discussion of downsides to our chosen approach is not swept off the table but rather addressed head on: http://www.bredemeyer.com/pdf_files/WhitePapers/Key%20Decisions%20Template.doc

We also encourage architects to “connect the dots,” tying decisions to their rationale–business strategy and architecture goals or lessons from our experience. The outcome of our thinking shows up in the code, but not the thought processes, the demands and drivers, the experiences, etc. that we were balancing as we made the architecture decisions. See http://www.bredemeyer.com/HotSpot/20040428EASoapBox.htm

http://www.rgoarchitects.com/nblog/2007/06/11/AgileArchitectureAndDocumentation.aspx
http://www.rgoarchitects.com/nblog/2007/05/13/EvolvingArchitectures.aspx