The problem I raised before still stands though; that the best way to transfer that knowledge is in a dynamic context, not a static book.
At least to me, the most important lessons isn't just why architectureA is the best choice, it is why architectureB..X were excluded. This information just isn't going to get in a book
To illustrate my point of view take ValueObjects...the most hideous anti-pattern ever It is nothing more than a workaround to reduce network overhead, yet how many people have read "ValueObjects are a good J2EE pattern" and then use them in their single JVM architecture? Or even use the full EJB stack in a single VM? The reason they do this is because they do not understand the rationale for this pattern, the pros and the cons. They don't see the bigger picture.
I think the only way this kind of information can really be passed on is through a group of people discussing the architecture, working through the pros/cons etc. Note, I am not talking about architecting to the nth degree, not at all. I am simply saying that a dynamin discussion is in my experience the only way to really pass on all this information.
i21 do (BTW ) do architecture reviews, project health checks, project kick starts etc....