Forse vengo presentato come "architetto del software" ai clienti perché tutti gli altri preferirebbero non essere l'oggetto di qualsiasi ira che il cliente è pronto a scatenare. (I clienti non visitano spesso quando le cose vanno bene.)
Ad ogni modo, per alcune parti del software che il mio gruppo sviluppa, sono probabilmente la cosa più vicina ad un "architetto del software". È una descrizione del lavoro un po' nebulosa o forse fasulla, come menzionato da alcune altre risposte. Il mio vero titolo è Principal Engineer.
Penso che diventare un "architetto del software" richieda un sacco di esperienza con il proprio software, così come la comprensione di come funzionano altri pezzi di software simili. Questa esperienza e comprensione non avviene da sola, anche se si lavora sulla stessa area per più di 20 anni. Penso che ci sia un'attitudine che devi avere verso la tua carriera che include:
- Dovresti voler capire tutti i piccoli pezzi del prodotto - non solo sapere che esistono, ma capire la loro implementazione, le limitazioni, il debito tecnico, ecc. associato ad ogni parte del sistema.
- Dovresti imparare come interagisce con altri software - software che scrivi e software complementari, e software della concorrenza.
- Dovresti capire come i tuoi clienti usano il software, e anche di cosa hanno bisogno.
Puoi lavorare nella stessa azienda per 20 anni e non raggiungere nessuno di questi obiettivi, quindi hai bisogno di più del semplice tempo.
Il modo migliore per fare il numero 1 è fare esperienza nello sviluppo di quanti più pezzi di software puoi. Correggere i bug, aiutare con le caratteristiche, parlare con gli sviluppatori che possiedono ogni pezzo. Capire il "debito tecnico" associato a tutti i pezzi vi aiuterà a capire quanto tempo ci vorrà per cambiare qualcosa, quanto sarà buggato e quando sarà il momento di riscriverlo. Se ci sono più soluzioni, quella che comporta grandi cambiamenti nel codice con un sacco di debito tecnico è probabilmente più rischiosa e da cui stare alla larga.
Un buon modo per imparare la #2 di cui sopra è usare il software da soli.
Il modo migliore per realizzare la #3 di cui sopra è parlare con i clienti, visitarli, e guardarli usare lo strumento. C'è una tendenza, credo, per gli sviluppatori di software ad essere isolati dai clienti, vivendo nel proprio mondo dove pensano di capire cosa vuole il cliente, perché lo vuole e come darglielo. Ogni volta che interagisco con qualcuno che sta effettivamente usando il software, è un'esperienza che apre gli occhi e spesso mi fa ripensare alle caratteristiche esistenti o mi dà idee su quelle nuove.