Mi chiamo Ronan e dirigo il team di Ingegneria del Software Quantistico presso Equal1. Progettiamo e realizziamo computer quantistici completamente integrati utilizzando tecnologie avanzate basate sullo spin. Equal1 ha sedi in Irlanda, Stati Uniti, Canada, Giappone, Romania e Paesi Bassi, dove vivo. Prima di questo incarico, ho lavorato presso Qblox, un’azienda che produce sistemi di controllo quantistico.

In Equal1, mi concentro sulla creazione del sistema full-stack che gestisce il nostro computer quantistico ad alte prestazioni RacQ. Questo sistema è progettato per scalare fino a migliaia di qubit logicamente corretti e oltre. Alcuni lo definiscono il “cervello” dei processori quantistici (QPU).

Trovo il mio lavoro affascinante perché ogni giorno c’è qualcosa di nuovo da imparare e ho la fortuna di lavorare con colleghi fantastici e competenti. Ho aperto questo blog per condividere ciò che ho imparato; ovviamente, senza svelare alcun segreto!

Non esitare a contattarmi via email all’indirizzo ronan oppure connettiti su LinkedIn se vuoi saperne di più!

Avvertenza: Sebbene lavori presso Equal1, questo blog è un progetto personale e non riflette le opinioni del mio datore di lavoro. I pensieri, le riflessioni e le opinioni qui condivise sono esclusivamente miei e non sono stati esaminati, approvati o modificati da nessun altro.

Architettura di sistema in sintesi Link to heading

Durante la mia esperienza in Qblox, il mio ruolo era quello di architetto di sistema. Di seguito è riportato un promemoria relativo al ruolo che ricoprivo all’epoca.

Il ruolo di sysarch Link to heading

Questa è una domanda che mi viene posta molto spesso: cosa ci si aspetta esattamente da un architetto di sistema (sysarch)? La risposta varia a seconda dell’azienda, del paese in cui opera e del settore di attività. Tuttavia, un concetto rimane costante: Comunicazione.

Sì, il ruolo dell’architetto è quello di comunicare idee complesse in modo semplice, sia ai team di sviluppo e ingegneria, sia ai dirigenti di alto livello, sia ai clienti. Tutto inizia con la comprensione del problema insieme al cliente e al team di prodotto, e questa è la parte più stimolante del ruolo: creare una soluzione che soddisfi il cliente!

Da qui si passa alla tradizionale analisi dei requisiti di sistema e, spesso, a una fase di prototipazione di prova di concetto, in cui di solito sono coinvolto attivamente. Successivamente si passa allo sviluppo del prodotto, dove ricopro il ruolo di responsabile tecnico, collaborando con team interfunzionali fino a quando il prodotto non è pronto. Infine, si passa all’assistenza post-lancio del prodotto.

Decisione architettonica Link to heading

Come si giunge a una decisione architetturale? Il ruolo dell’architetto non è necessariamente quello di decidere, ma piuttosto di inquadrare il problema consolidando gli input necessari per prendere una decisione. Ad esempio, il team di prodotto ("quanto costa sviluppare questo nuovo prodotto? Quali sono i tempi di immissione sul mercato?") o il team CxO ("vogliamo investire in questa nuova tecnologia? Qual è il ROI e la strategia a lungo termine?").

Si tratta di adottare un approccio cartesiano, ricercando e definendo i pro e i contro di ogni possibile soluzione senza giudizi soggettivi. Significa anche valutare il rapporto costi-benefici, considerando non solo lo sforzo di implementazione, ma anche la manutenzione a lungo termine, i costi operativi e il carico cognitivo sul team.

Ancora più importante, si tratta anche di negoziare l’allineamento sociale, perché qualsiasi decisione architetturale che gli ingegneri detestino o che i product manager non comprendano è destinata al fallimento. Raggiungere una decisione significa coinvolgere le persone nel processo. Per il ciclo Prodotto e Business, assicurarsi che la scelta apporti valore al business. Per il ciclo di ingegneria, chiedere un feedback agli ingegneri senior, in modo che si assumano la responsabilità della sua implementazione.

Criteri di refactoring Link to heading

Questa è una domanda ricorrente per tutte le aziende con un prodotto software: perché e quando dovremmo effettuare un refactoring? Si tende a pensare che quando i prodotti esistenti sono lenti e instabili, e ci vuole troppo tempo per risolvere i problemi a causa del debito tecnico accumulato, sia giunto il momento di effettuare un refactoring. Ma la risposta non è sempre quella giusta; il ruolo dell’architetto, infatti, è quello di prevenire il secondo effetto sistema.

La mia filosofia personale è quella di applicare le decisioni del primo giorno e verificarle con il test della “porta a doppio senso”: il refactoring è una porta a senso unico (quasi impossibile da invertire, come la scelta di un paradigma di database primario) o una porta a doppio senso (facile da modificare in seguito, come la scelta di una libreria interna)? Le porte a senso unico richiedono una validazione approfondita; le porte a doppio senso richiedono velocità.

Promuovere la cultura ingegneristica Link to heading

A prima vista, il ruolo del sysarch è anche quello di promuovere la cultura ingegneristica appropriata che crei valore sia per i team di ingegneria (meno interventi urgenti) sia per i team di prodotto (tempi di immissione sul mercato più rapidi).

Mentre l’idea generale è quella di investire ora nel tuo stack di ingegneria/software per risparmiare tempo in seguito nello sviluppo, la vera sfida è trovare il giusto equilibrio tra investire e sovraingegnerizzare: sviluppare gli strumenti e i componenti software giusti per semplificare lo sviluppo e la manutenzione del prodotto, piuttosto che sovraingegnerizzare qualcosa che non aggiunge valore.

Ciò significa anche che l’architetto deve comunicare frequentemente con i team di prodotto e con i team dirigenziali per promuovere il lavoro dei team che investono i propri sforzi in un’ingegneria a prova di futuro, anziché essere costantemente impegnati a risolvere problemi urgenti.

Ristrutturare un team Link to heading

A un certo punto, la semplice riorganizzazione del sistema non è più sufficiente, poiché entra in gioco la Legge di Conway: “Qualsiasi organizzazione che progetta un sistema produrrà un progetto la cui struttura è una copia della struttura di comunicazione dell’organizzazione stessa.”

La soluzione non è sempre quella di spostare le persone, ma piuttosto di riallineare il lavoro del team con l’organizzazione aziendale, in modo che la somma dei due team sia maggiore della somma delle loro parti. Se un team non crea abbastanza valore perché la sua struttura di comunicazione è inefficiente, si deve creare un sistema in cui il risultato del team sia definito da componenti migliori e da promesse API che offrano maggiore valore all’azienda. E se il team non riesce a creare nuovi componenti, si deve suddividere il lavoro in componenti più semplici con promesse API più immediate.

Ma, cosa ancora più importante, si tratta di promuovere l’allineamento sociale tra il team e l’organizzazione: immaginate un’azienda in cui il team si trasforma per creare più valore. Non sarebbe la situazione ideale?

L’intelligenza artificiale e il ciclo di progettazione Link to heading

In che modo l’IA ha cambiato il mio modo di lavorare? Moltissimo! Proprio come gli sviluppatori scrivono codice in base all’atmosfera, gli architetti devono essere più bravi a scrivere “progetti in linea con l’atmosfera” (così come requisiti di sistema in linea con l’atmosfera) che possano essere inseriti direttamente nei LLM come input per produrre codice.

L’intelligenza artificiale è di grande aiuto nella fase iterativa del design, poiché può generare rapidamente numerose varianti dello stesso progetto, consentendo un’esplorazione più veloce delle diverse opzioni. Questi progetti possono poi essere prototipati rapidamente per verificarne le ipotesi e la complessità di sviluppo.

Ma, cosa ancora più importante, è fondamentale ricordare che l’intelligenza artificiale non è qui per sostituire gli ingegneri, bensì per potenziarne le capacità e la creatività. È uno strumento per migliorare il processo di progettazione, non uno strumento per sostituire il giudizio e la competenza ingegneristica.

Ad esempio, osservate il diagramma qui sotto: quanti LLM vi diranno che il diagramma a destra mostra un errore sul qubit 3 (Z ₂ Z ₃ ), mentre in realtà si tratta di un errore bizantino sui qubit 1 e 2? (spiegazioni complete)

Alcune illustrazioni selezionate Link to heading