È almeno dagli inizi degli anni 2000 che sono sorti numerosi dibattiti su quanto un software architect dovrebbe mettere le mani sul codice: alcuni sostengono che la monotonia dei compiti di coding interferisca con la sua capacità di focalizzarsi su decisioni e compiti più importanti e prioritari ma c’è anche chi pensa che quello sia l’unico modo per questa figura di comprendere al meglio i sistemi che supervisiona.
Il report “Software Architecture and Design InfoQ trends” di Aprile 2021 parla di “architetti come leader tecnologici” inserendoli nei futuri trend senza approfondire il tema ma limitandosi ad aggiungere che “comprendere tutti i modelli di leadership emergenti, gli anti-pattern e le tecniche è essenziale per un moderno software architect”.
Cosa significa questo trend in termini di quanto un’organizzazione dovrebbe richiedere ai propri architetti di fare coding? E come influisce sugli architetti che vogliono farlo rispetto a quelli che non lo fanno? Qui di seguito si descrivono i diversi scenari in cui i software architect possono trovarsi, le modalità più diffuse con cui le organizzazioni gestiscono il loro coinvolgimento nella codebase e cosa possono fare coloro che non hanno alcuna intenzione di dedicarsi al coding.
Le 4 interpretazioni del ruolo del software architect
Ci sono molti modi in cui il ruolo di software architect può essere svolto all’interno di un’organizzazione e ciascuno comporta un diverso livello di responsabilità per la codebase, dal coinvolgimento diretto al completo disinteressamento.
Ci sono aziende in cui gli architetti ricoprono un lavoro pratico molto simile a quello di ad specialista delle infrastrutture: usando il software di virtualizzazione, i team tecnici avevano la possibilità di creare su richiesta i propri ambienti di deployment – o anche ambienti di produzione – sebbene entro i limiti delle specifiche approvate. Questi architetti si sono concentrati sulla gestione dell’infrastruttura di sistema, sulla supervisione degli sviluppatori e sulla definizione di standard relativi ai tipi di database o sui sistemi operativi. Le decisioni sui dispositivi mobile sempre più diffusi, per esempio, ricadevano però sui team di sicurezza IT piuttosto che sull’architetto.
Una seconda strada è quella scelta ad esempio anche da una società di software della Fortune 500 che aveva al suo interno centinaia di team di software separati. In questo caso c’è un vantaggio considerevole nel creare degli standard, specialmente per quanto riguarda gli strumenti, i vendor e i costi di licenza, ma in alcuni di questi gruppi gli architetti facevano turn over periodici tra i team di software specificamente per incorporare e scrivere software, con una durata di tre o sei mesi ogni volta. Questa rotazione serviva per mantenere l’architetto aggiornato sullo stato del software dandogli anche l’opportunità di considerare il trasferimento in un ruolo da ingegnere.
Una terza possibilità è quella di interpretare il ruolo di architetto come una promozione di una posizione di ingegnere. Gli architetti rivedono i progetti, discutono la strategia e coltivano progetti collaterali dando reali contributi tecnici, poi dopo un anno o due, escono da questo ruolo e tornano all’ingegneria. In questo modo quella dell’architettura diventa un’attività temporanea che fornisce agli ingegneri del software una visione più ampia delle operazioni tecniche dell’azienda.
La quarta e ultima modalità per interpretare il ruolo di software architect è quello delle strutture di dipartimento software più tradizionali in cui tipicamente c’è un team di sviluppo web, un gruppo di specialisti di database e alcuni programmatori che lavorano su ciò che riguarda l’Electronic Data Interchange. In questo caso, un membro di ciascuno di questi tre gruppi riceve la denominazione di architetto che collabora alle decisioni di architettura di più alto livello e, contemporaneamente, supervisiona le attività quotidiane del suo rispettivo gruppo.
Quale futuro per gli architetti che non toccano il codice?
La maggior parte delle organizzazioni si aspetta che l’architetto abbia uno scopo più ampio rispetto a quello di occuparsi di coding e questo è il reale problema. Col tempo, un programmatore web è destinato ad avere una conoscenza più diretta dello sviluppo web di un architetto che supervisiona un intero sistema soprattutto se quello stesso architetto passa molto del suo tempo a scrivere codice per un altro gruppo di sviluppo.
Tutti gli esempi fatti precedentemente riportano una visione di software architect come leader tecnico e servirebbe ora definire meglio le sue responsabilità. Cosa succede, ad esempio, ad un architetto che vuole fermarsi al livello decisionale più alto e non mettere mai le mani sul codice nel quotidiano?
In un’azienda, gli utenti finali sono probabilmente membri di dipartimenti interni, lato business, che non si preoccupano di specifiche come le implementazioni JavaScript o le API che collegano un database e vogliono solo capire il sistema nel suo complesso. Questo ha portato a pensare agli architetti come a persone che illustrano i sistemi disegnando diagrammi con cerchi e frecce: se questo viene fatto bene, ci può essere ancora spazio per qualche persona così. Per esempio, ci possono essere frequenti dispute all’interno dell’IT su problemi di integrazione del sistema e , quando vengono coinvolti i fornitori esterni, queste dispute possono portare a problemi con gli ordini di acquisto, i contratti di supporto e la compliance legale. Un architetto potrebbe in queste situazioni essere la persona in grado di portare valore ricoprendo quasi un ruolo di CTO.
Le organizzazioni più grandi potrebbero anche voler avere uno architetti di questo tipo per ogni unità di business: se hanno una conoscenza specifica dello stack tecnologico complessivo dei sistemi così come della parte più commerciale, possono trasformare il proprio ruolo e prendere più spazio in azienda.
Molti software architect sono già leader tecnici che costruiscono prototipi per proof of concept e possono anche dirigere la progettazione iniziale e l’implementazione di nuove tecnologie. Quelli che non lo sono, possono ancora anche prendere la certificazione Srum, diventare esperti di Six Sigma, o database admin o specialisti DevOps. Come visto finora però, è sempre importante che ricordino che per ogni azienda oggi vale una diversa definizione di architetto ed è quindi necessario per i professionisti saper adattare il proprio lavoro alle definizioni che incontrano nel loro percorso professionale.
