Technology Strategy & Fractional CTO
Assessment architetturali, roadmap tecniche, decisioni build vs buy, valutazione di soluzioni e governance di prodotto o progetto.
Solutions Architect · Fractional CTO
Trasformo complessità tecnologica in sistemi sostenibili.
Aiuto aziende e team a mettere a fuoco problemi complessi, definire architetture pragmatiche e guidarne l’implementazione.
02
Profilo
Strategia e architettura, con i piedi nell’implementazione.
Il mio lavoro comincia prima del codice: dal problema, dai vincoli e dalle decisioni che rendono una soluzione davvero sostenibile.
Il mio percorso inizia con lo sviluppo software e il web engineering, poi si estende a sistemi distribuiti, cloud, integrazioni e responsabilità architetturali. Questa base hands-on mi permette di lavorare sul piano strategico senza perdere il contatto con ciò che un team dovrà realmente costruire e gestire.
Metto in relazione requisiti di business e realtà tecnica, bilanciando costi, tempi, manutenibilità e operatività. L’obiettivo non è introdurre più tecnologia, ma prendere decisioni migliori e creare sistemi che possano evolvere senza trasformarsi in un vincolo.
03
Cosa faccio
Intervengo dove “decisioni tecniche“ e “impatto sul business“ si incontrano.
Solution & Software Architecture
Disegno ed evoluzione di applicazioni distribuite, API, flussi dati e percorsi realistici di modernizzazione del legacy.
Cloud & DevOps
Architetture cloud, pipeline di delivery, osservabilità e infrastrutture pensate per essere gestibili anche dopo il go-live.
System Integration
Connessione affidabile tra applicazioni, servizi e dati eterogenei, limitando il software custom quando non aggiunge valore.
Engineering & Technical Leadership
Validazione tecnica hands-on, codebase assessment, governo dello sviluppo e supporto ai team nelle decisioni complesse.
AWS, Docker, CI/CD, PHP, .NET, JavaScript, API, database e search sono strumenti: la scelta dipende dal problema, dal contesto e dal costo di gestione.
04
Come lavoro
Le scelte tecniche devono restare collegate a requisiti ed evidenze.
Prima comprendo il sistema esistente. Poi distinguo ciò che serve dalla soluzione già immaginata, valuto build vs buy e preferisco integrare o configurare quando basta. Il codice custom è una scelta, non un riflesso.
- 01
Comprendere
Contesto, obiettivi, persone, vincoli e sistema esistente.
- 02
Valutare
Separare requisiti e soluzioni, verificare rischi e alternative.
- 03
Disegnare
Definire un’architettura tracciabile, sostenibile e proporzionata.
- 04
Validare
Usare evidenze e prove mirate; una PoC resta un esperimento.
- 05
Implementare ed evolvere
Guidare la delivery e adattare le decisioni a ciò che emerge.
05
Decisioni in contesti reali
Architetture pensate per evolvere, decidere e modellare complessità.
Tre casi anonimi raccontati attraverso il problema, i vincoli e le decisioni prese. Le tecnologie restano sullo sfondo: il centro è il ragionamento architetturale.
01EVOLVE
Identity & Wallet condivisi
Evolvere un ecosistema digitale frammentato verso una piattaforma condivisa di Identity & Wallet
Come si introduce un'identità comune in prodotti digitali già esistenti senza riscriverli?
La sfida
Il vero problema non era implementare API di autenticazione o pagamento. La difficoltà consisteva nell'introdurre una nuova fonte autorevole per identità e operazioni Wallet all'interno di un ecosistema che possedeva già utenti, dati, regole di business e traffico in produzione. Le applicazioni esistenti non potevano essere semplicemente fermate e riscritte, e una migrazione immediata avrebbe legato il successo della nuova piattaforma alla modifica simultanea di diversi sistemi indipendenti.
Il mio ruolo
Ho lavorato trasversalmente su architettura, governance tecnica e validazione dell'implementazione. La mia responsabilità è stata analizzare l'ecosistema esistente, identificare i confini tra i sistemi, valutare il modello di integrazione proposto, definire la strategia di adozione progressiva e verificare che le singole decisioni implementative rimanessero compatibili con l'architettura di lungo periodo. Questo ha significato anche fare da ponte tra requisiti di business, team di implementazione esterni e vincoli tecnici dei prodotti esistenti.
La decisione
Ho scelto una strategia di migrazione incrementale invece di una sostituzione big bang. La transizione è stata articolata in fasi successive: sovrapposizione del nuovo livello di identità, introduzione trasparente nei prodotti esistenti, progressivo allineamento dei comportamenti e infine migrazione completa. La nuova piattaforma viene quindi introdotta attorno alle applicazioni esistenti e diventa progressivamente autorevole man mano che ciascun prodotto dimostra la propria compatibilità con il modello condiviso.
Risultato
La piattaforma condivisa di Identity e Wallet ha raggiunto le fasi finali di validazione con le funzionalità principali di autenticazione, ciclo di vita dell'utente, Wallet e amministrazione integrate e testate. Gli scenari di controllo degli accessi sono stati verificati sia per utenti autorizzati sia per utenti autenticati ma non autorizzati. È stata inoltre definita una roadmap di adozione progressiva che permette di procedere senza richiedere un cutover simultaneo dell'intero ecosistema. Il risultato non è quindi soltanto un nuovo servizio di autenticazione, ma un percorso architetturale per far convergere prodotti esistenti verso una piattaforma comune.
Approfondisci il caso
Contesto
Un ecosistema digitale maturo era cresciuto nel tempo attorno a diversi prodotti indipendenti, ciascuno con il proprio ciclo di vita degli utenti, le proprie modalità di autenticazione e comportamenti applicativi specifici. L'obiettivo era introdurre un livello di identità condiviso e una funzionalità Wallet comune, preservando i prodotti esistenti e accompagnando progressivamente gli utenti verso un'esperienza unificata.
Vincoli
Le applicazioni esistenti dovevano continuare a funzionare durante l'intera transizione. Le assunzioni legacy sull'identità non potevano scomparire da un giorno all'altro, l'esperienza utente non poteva dipendere dalla migrazione contemporanea di tutti i prodotti e l'architettura doveva consentire adozione progressiva e rollback. Era inoltre necessario minimizzare gli interventi invasivi sulle applicazioni mature ed evitare che la piattaforma condivisa diventasse un nuovo monolite contenente logiche di business specifiche dei singoli prodotti.
Perché
Una riscrittura coordinata avrebbe concentrato il rischio tecnico e operativo in un unico rilascio e avrebbe richiesto che più prodotti raggiungessero contemporaneamente lo stato necessario alla migrazione. L'approccio progressivo permette invece di validare architettura e comportamento su integrazioni reali, mantenendo i sistemi legacy disponibili come fallback controllato. Inoltre separa la decisione strategica di adottare una piattaforma condivisa dalla tempistica tattica con cui ciascun prodotto può migrare.
Trade-off
La strategia incrementale accetta deliberatamente una maggiore complessità architetturale temporanea. Durante la migrazione devono convivere assunzioni legacy e nuovo modello di identità, e i percorsi di integrazione devono supportare stati transitori. È più complesso rispetto alla progettazione di una piattaforma greenfield, ma questa complessità di breve periodo riduce il rischio della migrazione, permette rollout indipendenti e consente di validare le assunzioni prima di rendere la nuova piattaforma pienamente autorevole.
Cosa ho imparato
Le migrazioni di piattaforma raramente sono soltanto migrazioni tecnologiche: sono migrazioni di autorità, comportamenti e responsabilità. Avere un sostituto tecnicamente migliore non è sufficiente; l'architettura deve modellare esplicitamente il periodo nel quale vecchie e nuove assunzioni convivono. Questa esperienza ha rafforzato la mia preferenza per migrazioni reversibili e guidate da evidenze rispetto alle grandi riscritture coordinate.
Architettura
L'architettura introduce funzionalità condivise di Identity e Wallet dietro API esplicite, mentre le applicazioni esistenti mantengono le proprie responsabilità specifiche di prodotto. Layer di integrazione consentono ai sistemi legacy di adottare progressivamente i nuovi servizi. Identità, operazioni Wallet, profili applicativi e comportamenti di business vengono trattati come responsabilità distinte invece di essere accorpati in un'unica applicazione.
Prodotto esistente A ─┐
Prodotto esistente B ─┼─> Layer di integrazione ─> Identity condivisa
Prodotto esistente C ─┘ └─> Wallet condiviso
│
└──────── Logiche di business specifiche nel singolo prodottoNota di riservatezza. Il cliente, i nomi dei prodotti, i dati commerciali e i dettagli implementativi non necessari alla comprensione del caso sono stati omessi o generalizzati per ragioni di riservatezza.
02DECIDE
Moderazione AI ibrida
Progettare un sistema di moderazione assistito dall'AI senza delegare ogni decisione all'LLM
Non tutte le decisioni che possono essere delegate all'AI dovrebbero esserlo.
La sfida
La moderazione non era un singolo problema di classificazione. Regole diverse avevano caratteristiche profondamente differenti: alcune potevano essere dimostrate deterministicamente, altre richiedevano interpretazione. La vera sfida era quindi stabilire quali decisioni appartenessero al software deterministico, quali beneficiassero realmente di un LLM e come combinare entrambi gli approcci senza perdere la tracciabilità della decisione finale.
Il mio ruolo
Ho contribuito all'architettura e alla governance del sistema di moderazione, con particolare attenzione alla decomposizione delle policy tra responsabilità deterministiche e semantiche. Ho revisionato l'interazione tra rule engine applicativo, orchestrazione del workflow e valutazione tramite LLM, contribuendo alla definizione degli acceptance criteria e a un processo di validazione basato su evidenze. L'obiettivo era assicurare che l'implementazione rimanesse un sistema decisionale governabile e non diventasse semplicemente un wrapper opaco attorno a un modello AI.
La decisione
Ho scelto un'architettura ibrida. Le regole verificabili oggettivamente rimangono deterministiche e vengono eseguite dal rule engine applicativo. Le regole che richiedono interpretazione vengono delegate a uno specifico livello di valutazione semantica basato su LLM. L'orchestrazione collega i diversi componenti, mentre l'applicazione conserva la responsabilità di combinare le evidenze e produrre la decisione finale autorevole.
Risultato
La proof of concept iniziale si è evoluta in un sistema di moderazione integrato con responsabilità deterministiche e semantiche esplicite, output AI strutturato e audit trail a livello applicativo. L'implementazione è stata verificata attraverso acceptance criteria e sono state applicate remediation mirate nei punti in cui il comportamento reale divergeva da quello atteso. L'architettura risultante consente di automatizzare la moderazione senza trasformare il modello linguistico nella fonte incontrollata di verità per ogni decisione.
Approfondisci il caso
Contesto
Una piattaforma online di grandi dimensioni aveva la necessità di automatizzare parte di un processo di moderazione storicamente caratterizzato da un significativo intervento umano. Alcune violazioni delle policy erano verificabili oggettivamente attraverso i dati applicativi, mentre altre dipendevano dal linguaggio, dal contesto e dall'interpretazione semantica. L'AI generativa offriva la possibilità di automatizzare queste ultime, ma utilizzare un LLM come unico decisore avrebbe reso il sistema complessivamente meno prevedibile e più difficile da verificare.
Vincoli
Il sistema doveva integrarsi con una piattaforma e un workflow operativo già esistenti. Le decisioni dovevano rimanere spiegabili e auditabili, la valutazione semantica doveva produrre output strutturati e consumabili automaticamente e i fatti deterministici non potevano essere sovrascritti semplicemente perché un modello AI forniva un'interpretazione differente. L'architettura doveva inoltre permettere alle singole regole e ai comportamenti AI di evolvere indipendentemente.
Perché
Delegare ogni regola a un LLM avrebbe aumentato variabilità, costi e complessità di debugging senza fornire alcun vantaggio per fatti che il software tradizionale può determinare esattamente. All'opposto, cercare di codificare interpretazioni linguistiche complesse attraverso regole deterministiche avrebbe prodotto euristiche fragili. La separazione consente di affrontare ogni classe di problema con il meccanismo più appropriato.
Trade-off
Il modello ibrido introduce più componenti e richiede un contratto esplicito tra valutazione semantica ed esecuzione deterministica. È strutturalmente più complesso rispetto all'invio dell'intera policy di moderazione a un singolo modello. Questa complessità aggiuntiva è stata accettata in cambio di garanzie deterministiche dove possibili, evoluzione indipendente delle regole, maggiore osservabilità e un confine chiaro rispetto all'autorità concessa all'AI.
Cosa ho imparato
Una delle decisioni architetturali più importanti nell'adozione dell'AI consiste nello stabilire cosa non debba essere AI. Gli LLM sono preziosi quando ambiguità e interpretazione semantica appartengono intrinsecamente al problema; sono invece un cattivo sostituto della logica deterministica quando i fatti possono essere verificati direttamente. Questa esperienza ha rafforzato il mio approccio agli elementi AI come capability circoscritte all'interno di sistemi decisionali più ampi, dotate di autorità, contratti, evidenze e failure mode espliciti.
Architettura
La piattaforma invia i contenuti da valutare a un workflow di orchestrazione. I controlli semantici vengono eseguiti da un modello linguistico specializzato che restituisce un output strutturato, comprendente motivazioni della decisione e informazioni di confidenza. Il rule engine applicativo valuta le condizioni deterministiche e le combina con le evidenze semantiche. La decisione autorevole risultante e le evidenze che l'hanno prodotta vengono infine conservate in un audit trail.
Piattaforma
│
v
Orchestrazione ─────────────> Valutazione semantica (LLM)
│ │
│ v
└──────────────────────────> Evidenze strutturate
│
v
Rule Engine deterministico
│
v
Decisione finale
│
v
Audit TrailNota di riservatezza. Il cliente, i nomi delle piattaforme, le policy di moderazione, i dati di produzione e i dettagli implementativi non necessari sono stati omessi o generalizzati per ragioni di riservatezza.
03MODEL
Preventivazione CNC spiegabile
Trasformare il know-how manifatturiero in un motore di preventivazione CNC spiegabile
La parte difficile non era leggere un modello 3D. Era trasformare il know-how implicito di un esperto in regole esplicite e verificabili.
La sfida
Interpretare la geometria era soltanto il primo livello del problema. Un preventivo richiede di comprendere quale materiale debba essere realmente rimosso, quali lavorazioni siano necessarie, come ciascuna operazione modifichi il grezzo residuo, se un utensile possa fisicamente raggiungere una determinata regione, come materiale e utensili influenzino la strategia di lavorazione e quali informazioni non possano essere dedotte in modo affidabile dalla sola geometria. La sfida centrale era quindi trasformare il ragionamento manifatturiero implicito in obblighi computazionali espliciti, spiegabili e verificabili.
Il mio ruolo
Ho lavorato sulla decomposizione del problema di preventivazione in fasi computazionali, sull'architettura della pipeline di elaborazione, sui modelli di feature e degli obblighi di lavorazione, sulla strategia di validazione e sulla governance tecnica delle successive sperimentazioni. Una parte sostanziale del mio ruolo è consistita nel determinare ciò che il sistema potesse legittimamente dedurre in ogni fase, impedendo che approssimazioni sperimentali venissero promosse prematuramente a logica autorevole di preventivazione.
La decisione
Ho scelto di costruire il motore come una pipeline guidata da evidenze invece che come uno stimatore monolitico. La geometria viene progressivamente trasformata in feature manifatturiere, obblighi di lavorazione e transizioni esplicite dello stato del grezzo. Ogni operazione deve essere supportata da evidenze quali applicabilità geometrica, accessibilità dell'utensile e vincoli specifici della lavorazione prima di poter contribuire in modo autorevole al modello finale.
Risultato
Il progetto si è evoluto dal riconoscimento iniziale di feature geometriche verso una pipeline di lavorazione capace di rappresentare obblighi manifatturieri, evidenze specifiche delle operazioni e transizioni esplicite dello stato del grezzo. Operazioni inizialmente sperimentali vengono promosse a comportamento autorevole soltanto dopo il superamento di gate di validazione dedicati, mentre la preventivazione rimane bloccata nei punti in cui le evidenze sulle lavorazioni successive non sono ancora sufficienti. Il sistema aumenta quindi progressivamente le proprie capacità senza nascondere l'incertezza dietro stime apparentemente precise.
Approfondisci il caso
Contesto
Un'azienda manifatturiera voleva ridurre il lavoro manuale specialistico necessario per stimare tempi e costi di lavorazione CNC a partire dai particolari richiesti dai clienti. Gli input disponibili comprendevano modelli tridimensionali STEP e parametri commerciali, mentre gran parte delle conoscenze necessarie per produrre un preventivo attendibile risiedeva implicitamente nell'esperienza degli specialisti di produzione e non in un modello computazionale formalizzato.
Vincoli
Il sistema doveva operare su modelli CAD reali e non necessariamente ideali, evitando al tempo stesso di produrre falsa precisione. Il know-how manifatturiero non poteva essere ridotto a un'unica formula e le informazioni mancanti dovevano emergere esplicitamente invece di essere sostituite da assunzioni arbitrarie. Il modello doveva inoltre evolvere progressivamente confrontandosi con pezzi e dati di produzione reali. Un preventivo non poteva essere considerato affidabile soltanto perché il software era riuscito a produrre un valore numerico.
Perché
Una previsione diretta STEP-to-time avrebbe potuto produrre numeri plausibili senza spiegare perché fossero corretti. Gli errori sarebbero stati difficili da diagnosticare e il feedback degli esperti difficile da incorporare. Modellando esplicitamente i concetti manifatturieri intermedi, ogni discrepanza può invece essere ricondotta a un'assunzione specifica: riconoscimento delle feature, definizione del grezzo, accessibilità, scelta delle lavorazioni, utensili o stima dei tempi. Le rappresentazioni intermedie diventano quindi sia componenti computazionali sia evidenze utilizzabili per il debugging e la validazione.
Trade-off
L'architettura privilegia deliberatamente spiegabilità e validazione progressiva rispetto alla capacità di produrre rapidamente un preventivo per qualsiasi pezzo. Questo significa accettare stati esplicitamente bloccati o irrisolti quando le evidenze disponibili non sono sufficienti. Lo sviluppo è più lento rispetto a uno stimatore euristico che restituisce sempre un numero, ma gli errori rimangono osservabili e il sistema può distinguere il comportamento dimostrato dalle approssimazioni ancora sperimentali.
Cosa ho imparato
Il know-how complesso di dominio non dovrebbe essere automatizzato cercando semplicemente di riprodurre la risposta finale dell'esperto. È più robusto identificare le decisioni intermedie che l'esperto compie e renderle esplicite, verificabili e osservabili. Questo progetto ha rafforzato la mia preferenza per pipeline supportate da evidenze: quando il software compie un'inferenza rilevante, dovrebbe conservare anche informazioni sufficienti a spiegare perché quell'inferenza sia stata autorizzata a diventare parte del comportamento del sistema.
Architettura
Il sistema utilizza una pipeline di elaborazione a stadi. La geometria CAD viene interpretata per ricavare evidenze geometriche e feature manifatturiere. Da queste vengono generati obblighi di lavorazione associati a requisiti di setup e accessibilità. Le operazioni validate trasformano stati espliciti del grezzo e gli obblighi successivi vengono rivalutati rispetto alla geometria risultante. Le evidenze relative a operazioni e utensili possono quindi alimentare il modello dei tempi di lavorazione e, successivamente, il livello commerciale di preventivazione.
Modello STEP / CAD
│
v
Geometria e riconoscimento feature
│
v
Obblighi di lavorazione
│
v
Evidenze di setup / utensile / accessibilità
│
v
Operazione di lavorazione validata
│
v
Transizione dello stato del grezzo
│
v
Obblighi successivi
│
v
Modello dei tempi di lavorazione
│
v
PreventivoNota di riservatezza. Il cliente, i dati manifatturieri proprietari, i parametri commerciali e i dettagli che potrebbero rivelare know-how produttivo sono stati omessi o generalizzati.
06
Content hub
Idee ed esperienze per prendere decisioni tecnologiche migliori.
Contenuti selezionati dal mio ecosistema editoriale. Qui trovi la chiave di lettura; l’articolo completo resta sulla fonte originale.
L'AI funziona meglio quando le assegni un compito preciso all'interno di un processo governabile.
Quando l'AI è un componente del sistema, non la soluzione magica
Titolo originale: Quella volta che siamo andati online con il nuovo ecommerce e ci siamo accorti che mancavano le foto dei prodotti
Un problema operativo nato durante la migrazione di un e-commerce si trasforma in un piccolo sistema decisionale: ricerca progressiva dei candidati, Computer Vision per raccogliere evidenze semantiche, regole deterministiche per accettare o scartare i risultati e metadati per conservarne la provenienza. Non AI come scorciatoia, ma come componente specializzato di una pipeline tracciabile.
Una parte crescente del lavoro tecnico consiste nel decidere dove non scrivere codice, cosa standardizzare e quale complessità vale davvero la pena introdurre.
Il valore dell'architettura sta nelle decisioni, non nella quantità di codice
Titolo originale: Il mio 2025: un anno di architetture, standard e scelte tecniche consapevoli
Una retrospettiva su un anno trascorso soprattutto dentro sistemi esistenti: legacy da evolvere senza riscritture eroiche, infrastrutture da rendere riproducibili, configurazioni implicite da trasformare in regole verificabili e tecnologie da scegliere in funzione dei vincoli reali. Il filo conduttore non è uno stack, ma la riduzione del rischio e della complessità non necessaria.
Quando non puoi ricostruire chi ha cambiato cosa, quando e perché, il problema non è Git: è la governabilità del software.
Il version control non è uno strumento: è disciplina ingegneristica
Titolo originale: J’accuse: Contro i Programmatori che Ignorano Git
Partendo da una codebase reale piena di backup manuali, dipendenze duplicate e versioni impossibili da ricostruire, il post usa volutamente l'ironia per parlare di un principio molto serio: il software professionale deve conservare la propria storia. Version control, dependency management e processi ripetibili non sono formalismi, ma prerequisiti per collaborazione, manutenzione e responsabilità tecnica.
Parliamone
Hai un problema tecnologico complesso da mettere a fuoco?
Un primo confronto serve a capire il contesto, non a venderti una soluzione preconfezionata.