Analisi approfondite su architettura software, strategie di scalabilità, developer experience (DevX) e system design per imprese tecnologiche ad alta crescita.
Leggi in ordine la serie sulla governance
La maggior parte dei record di decisione conserva il verdetto e perde tutto ciò che più avanti ti direbbe se è ancora giusto. Quali campi si guadagnano il posto, perché l'esito atteso e l'assunzione fanno lavori diversi, e come far rispettare il record in CI, con un template e lo script per controllarlo.
Il contratto da cui dipendono i tuoi consumer non è quello nella tua specifica. È tutto ciò che possono osservare: l'ordine, i tempi, un campo che c'è sempre, il testo di un errore. Perché il versioning non può proteggerlo, perché il produttore non sa mai chi dipende da cosa, e cosa possono fare le due parti prima che un rilascio perfettamente conforme rompa qualcuno.
L'isolamento tra ambienti di solito si rompe senza un errore: una credenziale deriva, un binding viene aggiunto di fretta, e nessuno protesta finché qualcosa non scrive in produzione. Quattro livelli per rendere l'isolamento dimostrabile, ciascuno con il codice per farlo, dal rifiutarsi di avviarsi con la configurazione sbagliata al bloccare ogni promozione con un test negativo.
La due diligence misura lo stato di salute di un fornitore il giorno in cui firmi. Non dice niente su quanto ti costerà andartene, e quel numero non sta fermo. Perché il costo di uscita di una dipendenza comprata si accresce dopo la firma, dove si nasconde, e cosa decidere finché progettare l'uscita è ancora gratis.
La reversibilità non è una virtù che compri per sé stessa, è un'assicurazione, e il premio è limitato dal danno che copre. Perché pagare in modo uniforme è lo spreco vero, perché il costo di disfare una decisione si crea dopo la decisione e non nel momento in cui la prendi, e cosa registrare quando il conto non lo puoi prezzare in anticipo.
L'ultima mossa della serie: dopo aver scritto le decisioni, fatto rispettare i confini, isolato i dati e codificato il giudizio, resta una garanzia che nessun controllo tecnico raggiunge: chi ha l'autorità di decidere, e chi possiede la decisione quando cade tra i proprietari. Perché la governance è in fondo un problema di org-design, e cosa farci.
Una scorciatoia di scheduling per un sistema di invio email di massa funzionava in ogni ambiente e poi è collassata in produzione: migliaia di email mai inviate, migliaia spedite dieci volte. Mi ha insegnato che 'ha passato la review' non è mai stato lo stesso di 'è corretto', e perché la produzione di codice a velocità di macchina rende indifendibile appoggiarsi alla review umana.
Per una startup legal-tech dovevo garantire che solo i membri autorizzati di un tenant potessero toccarne i documenti. Il RAG non cambia il problema: aggiunge un layer di retrieval che fa perdere in silenzio un confine soft. Ecco perché l'isolamento dei tenant dev'essere un pre-filter rigido all'index, non un segnale di ranking, e perché deve fallire in sicurezza.
La promessa dell'AI multi-agente è che più agenti significhino un sistema più potente. Quel conto l'ho pagato una volta: un esperimento durato nove anni nello spezzare una piattaforma tra dodici team con ownership separate. Ecco cosa mi ha insegnato sul perché il numero di agenti è un costo che paghi, non una capacità che guadagni.
Ho aperto il mio repo e ho scoperto che la regola che doveva sorvegliare la mia architettura non faceva rispettare nulla. Ecco come l'ho trasformata in una fitness function che fa fallire la build quando qualsiasi codice, umano o AI, attraversa una linea che non dovrebbe.
Nel 2016, al mio primo incarico di architettura, un mentore mi disse che la documentazione era un deliverable importante quanto il codice. Ecco perché le decisioni architetturali che non scrivi tornano sempre come debito.