Provavelmente o elemento mais importante do documento é a complexidade da arquitetura sendo projetada. Uma aplicação cliente-servidor em duas camadas com uma lógica de negócio complexa pode ser muito simples arquitetonicamente. Pode-se exigir um diagrama que descreva os principais componentes, e uma visão estrutural dos componentes principais, além de uma descrição do esquema de banco de dados, gerada automaticamente por ferramentas de banco de dados. Documentação deste nível é rápida para ser produzida e rotineira para ser descrita.
Outro fator a considerar é a longevidade da aplicação. Será que o sistema irá atender a um negócio de longo prazo, ou está sendo construído para lidar com uma necessidade de integração, ou é apenas um tapa buracoss até que o sistema definitivo seja instalado?
Projetos com poucas perspectivas de uma vida longa provavelmente não necessitam de uma grande quantidade de documentação. Ainda assim, isso não pode ser uma desculpa para eliminar algum código ou boa prática de design. Às vezes, esses sistemas paliativos sobrevivem por muito mais tempo do que o inicialmente previsto.
O próximo fator a considerar são as necessidades das várias partes interessadas no projeto. A documentação da arquitetura desempenha um importante papel na comunicação entre os vários membros da equipe do projeto, incluindo arquitetos, designers, desenvolvedores, testadores, gerentes de projeto, clientes, organizações parceiras e assim por diante.