Dal codice accumulato alla configurazione dichiarata.

In parte, e vale la pena capire quale parte, perché è la ragione più seria per modernizzare e la meno discussa nelle proposte commerciali.

Il rischio di concentrazione ha due componenti. La prima è la conoscenza tecnica del sistema — come è fatto, dove si mette le mani — e quella si trasferisce, faticosamente, a chiunque abbia le competenze. La seconda è la conoscenza del dominio: perché quel controllo esiste, quale caso reale ha prodotto quell'eccezione, cosa succede il 31 dicembre. Questa è la parte insostituibile, ed è quella che se ne va con la persona.

Il modello dichiarativo non fa magie, ma sposta il secondo tipo di conoscenza dal codice a un documento che una persona di dominio può leggere. Quando la regola "un ordine con pagamento anticipato non può essere spedito senza incasso confermato" è scritta in una condizione leggibile invece che dentro una funzione, chiunque conosca il mestiere può verificarla, discuterla e correggerla, anche senza sapere programmare.

Resta il lavoro di estrazione, che è la fase più difficile del progetto e che nessuno può fare al posto vostro: qualcuno deve sedersi con quella persona e mettere per iscritto ciò che sa. Il valore di quel lavoro, però, non dipende dal fatto che il progetto prosegua.

Quasi mai bloccati, spesso rallentati. Nella pratica esistono tre vie, in ordine di preferenza.

• Interfacce applicative, dove esistono: la strada migliore, perché il legacy mantiene il controllo della propria logica e le operazioni sono sincrone e verificabili.
• Scambio di file strutturati, che è la realtà più diffusa nei sistemi di una certa età: estrazioni periodiche in ingresso e file di ritorno. Funziona bene, a patto di progettare con cura la frequenza, la gestione delle differenze e cosa succede quando due mondi divergono.
• Lettura diretta della base dati, in sola lettura e concordata con chi mantiene il sistema: praticabile quando le altre due non ci sono, purché ci si limiti alla lettura.

Quello che non facciamo è scrivere direttamente nel database di un sistema legacy aggirando la sua logica applicativa. Sembra la scorciatoia che risolve tutto ed è la causa dei danni peggiori, che si manifestano mesi dopo e in forme difficili da ricondurre alla causa.

La domanda giusta non è quanto dura la modernizzazione, perché formulata così la risposta onesta è "anni" e non aiuta nessuno a decidere. La domanda utile è: quanto ci mette il primo dominio a essere in esercizio e a produrre valore da solo.

Per un perimetro ristretto e ben definito l'ordine di grandezza è di alcune settimane dalla sessione iniziale, più il tempo dell'integrazione con il legacy — che è la variabile più incerta e dipende interamente da cosa quel sistema espone e da quanto è disponibile chi lo mantiene. È per questo che la verifica di fattibilità è il secondo passo del percorso e non l'ultimo.

Da lì in poi il ritmo dipende da quanti domini volete portare e con quali risorse. La differenza rispetto a una riscrittura è che non esiste una data oltre la quale il progetto o riesce o è stato inutile: ogni dominio completato è valore acquisito, indipendentemente da quello che succede dopo.

Diventa una decisione molto più semplice di quanto lo sia oggi, per una ragione precisa: nel frattempo il perimetro del legacy si è ristretto e le sue regole sono state scritte.

Il motivo per cui oggi non potete spegnerlo non è che sia tecnicamente impossibile: è che nessuno sa esattamente cosa fa. Dopo che tre o quattro domini sono stati portati fuori e formalizzati, quello che resta dentro è un insieme più piccolo e meglio compreso. La sostituzione, a quel punto, è un progetto di dimensioni note invece di un salto nel buio.

Va però detto con franchezza che in molti casi non conviene comunque. Se il legacy si è ridotto a fare contabilizzazione e calcoli che funzionano da vent'anni senza dare problemi, sostituirlo è spesa senza ritorno. La modernizzazione riuscita non è quella che elimina il vecchio sistema: è quella che smette di esserne prigioniera.