I thought in suggesting this same document Russel.
As Martin Fowler himself says, architecture is the shared understanding of how things work.
Communication is necessary for good architecture understanding.
If we are in a well-known context, we can even move further with bad communication. However, when in enter in uncharted/complex territory, this understanding is necessary.
Therefore, before thinking in tool X or strategy Y, I would think if the communication is effective:
- “Do I understand the wording used by developers? Do they understand the terminology of testing?”
- “Do I understand why they take certain decisions?”
- “Do others know the necessary conditions to evaluate quality in our project?”
- “Are ways of reflecting upon how we work, so we can brainstorm and experiment ways to improve?”
In summary, I think it would a great risk and a bold assumptions to think one can sit in a cubicle (physical or mental), receive a bunch of changes and expect to be able to evaluate and communicate the necessary stuff in a reasonable time.
The “technical” can be sorted out afterwards.