Penso che la migliore definizione (più pratica e più accurata) di "architettura" sia "ciò a cui pensi quando pensi al tuo problema attuale in un modo utilmente più astratto". O per metterla in un altro modo, può essere un'analogia con il vecchio detto sul vincere la battaglia ma perdere la guerra. I programmatori vincono le battaglie, gli architetti vincono la guerra.
Parlare di architettura del software è scivoloso, perché la definizione stessa di architettura del software è scivolosa e cambia a seconda di chi si chiede, e quando. Un descrittore con cui la maggior parte delle persone sarebbe d'accordo è "gli architetti guardano il quadro generale"
A un'estremità dello spettro c'è un CTO o un CIO per il quale l'architettura riguarda le tecnologie e le piattaforme in cui l'azienda dovrebbe investire.
All'altra estremità, anche un normale programmatore di Joe/Jane pensa a come i pezzi del sistema a cui sta lavorando vanno insieme.
In mezzo, il team di quel programmatore potrebbe avere un architetto che passa le sue giornate ad assicurarsi:
- che il team stia adottando il giusto approccio generale per risolvere il problema;
- che i diversi sottosistemi su cui i programmatori stanno lavorando si integrino bene quando li mettono insieme;
- che il team stia risolvendo il problema giusto (a seconda della cultura e delle dimensioni dell'organizzazione questo potrebbe essere suddiviso in un ruolo diverso).
Questo potrebbe comportare un sacco di diagrammi UML, o potrebbe essere più pratico e coinvolgere più discussioni e lavagne, a seconda della cultura e delle dimensioni dell'organizzazione.
Se si tratta di un buon gruppo di sviluppo software, mi aspetto che queste discussioni coinvolgano i membri del team di progetto a tutti i livelli, ma in gruppi più medi potrebbero esserci più formalità e linee di divisione più rigide, e l'architetto potrebbe passare la maggior parte del tempo con i project manager, i pianificatori di progetto, i team leader, ecc.
In contesti organizzativi più grandi, spesso c'è molta enfasi sui formalismi per proteggere i lavoratori di rango da distrazioni. In organizzazioni più piccole, o in gruppi di sviluppo più acuti in organizzazioni più grandi, è più facile evitare che la collaborazione in team diventi una distrazione (e a volte è più facile convincere la direzione che si sa cosa è cosa).
Ci potrebbe essere un architetto al livello superiore che pensa a come i diversi sistemi aziendali lavorano insieme.
C'è un termine che a volte viene fuori nelle discussioni sul software, ma sorprendentemente non credo di averlo mai visto in una discussione sull'architettura: cross-cutting concerns.
Cross-cutting concerns sono questioni che riguardano l'intera applicazione, come il logging, la sicurezza, il modo in cui i dati circolano (code di messaggi vs event listeners vs, etc), e così via. I programmatori certamente pensano a queste cose e a come si riferiscono alle parti del progetto su cui stanno lavorando. Ma sarebbe anche ragionevole dire che le preoccupazioni trasversali sono (o sono una buona parte) della carne e delle bevande dell'architetto.
Inoltre, come dice un detto militare un po' più oscuro, "i privati studiano le tattiche, i generali la logistica":
La natura del ruolo dell'architetto è tale che lui o lei passa molto tempo a trattare con tutti i membri e livelli del team, incluso il pianificatore del progetto e il project manager (se non sono la stessa persona). Come ho detto sopra, mentre non sarei affatto sorpreso se una data organizzazione è molto formale riguardo alle linee tra le aree di responsabilità, non sarei nemmeno sorpreso se fosse il contrario - se il project manager e l'architetto del progetto e chiunque altro passasse molto tempo non solo a mentire, ma a collaborare e a chiacchierare. Quindi l'architetto potrebbe anche finire per fare un sacco di cose pratiche con la pianificazione del progetto e la metodologia di sviluppo del software.
(Nota, dove scrivo "programmatore", inserite il vostro titolo preferito: sviluppatore, ingegnere, ecc. Alcune persone (e alcune organizzazioni) cercano di inventare una gerarchia intorno a questi titoli, ma nessuno sembra avere le stesse definizioni quindi la distinzione non ha senso.