Quando immaginiamo un progetto web, tendiamo a pensare che i dati arrivino da un'API moderna, ben documentata e possibilmente accompagnata da un'interfaccia elegante.
Nella realtà aziendale i dati importanti possono vivere in sistemi sviluppati molti anni fa, scritti in linguaggi che la maggior parte degli sviluppatori web incontra soltanto negli articoli sulla storia dell'informatica.
È il caso del COBOL.
COBOL viene spesso citato come una curiosità sopravvissuta dal passato. In realtà continua a gestire processi centrali di banche, assicurazioni, pubbliche amministrazioni e aziende. Non perché nessuno abbia avuto il coraggio di sostituirlo, ma perché quei sistemi contengono decenni di regole operative e continuano a svolgere il proprio lavoro.
Nel progetto per un cliente del settore della distribuzione il problema non era riscrivere il gestionale.
Era permettere ai dati gestiti da quel sistema di arrivare sul web in una forma utile, controllata e comprensibile.
Il dato esisteva già
Catalogo, disponibilità, listini e offerte non nascevano nel sito.
Erano il risultato del lavoro quotidiano dell'azienda e vivevano nel gestionale. Chiedere di reinserirli manualmente nel CMS avrebbe significato creare una seconda versione della realtà.
Due archivi da aggiornare. Due possibilità di errore. Due risposte diverse alla domanda più semplice: qual è il prezzo corretto?
La prima decisione è stata quindi architetturale: il gestionale doveva rimanere la fonte dei dati operativi.
Il sito non avrebbe sostituito quel sistema. Avrebbe costruito sopra di esso un livello di consultazione adatto al web.
Il problema non è il linguaggio
Di fronte alla parola COBOL è facile concentrarsi sul linguaggio.
Ma in un'integrazione la domanda principale non è “con che cosa è scritto il sistema?”. È:
- quali dati può produrre;
- con quale frequenza;
- in quale formato;
- con quali identificativi;
- quali relazioni devono essere conservate;
- quali informazioni possono essere pubblicate;
- che cosa succede quando un dato manca o cambia.
Il gestionale può essere scritto in COBOL, Java o in una combinazione di formule Excel custodita da una persona sola. Il compito rimane costruire un contratto comprensibile tra due mondi.
Prima osservare, poi trasformare
I dati di un gestionale non sono progettati per il pubblico.
Contengono codici, abbreviazioni, convenzioni interne e strutture nate per esigenze amministrative o logistiche. Sono efficienti per chi conosce il sistema, non necessariamente per chi cerca un prodotto online.
Pubblicarli senza trasformazione avrebbe trasferito sul cliente finale la complessità dell'azienda.
È stato quindi necessario costruire una procedura capace di:
- ricevere le informazioni dal gestionale;
- riconoscere prodotti e relazioni attraverso identificativi stabili;
- normalizzare formati e valori;
- distinguere dati pubblici e interni;
- gestire campi mancanti;
- produrre una struttura adatta alla ricerca e alla navigazione;
- conservare traccia dell'ultimo aggiornamento valido.
Questa è la parte meno visibile dell'integrazione e spesso la più importante.
Trasferire un file è semplice. Capire che cosa significhi ogni riga è il progetto.
Un livello intermedio protegge entrambi i sistemi
Collegare direttamente il sito al cuore del gestionale può sembrare la soluzione più efficiente.
Significa però rendere il frontend dipendente dalla disponibilità, dai tempi di risposta e dai cambiamenti di un sistema nato per un altro contesto.
Un livello intermedio permette di separare le responsabilità.
Il gestionale esporta ciò che conosce. Una procedura controlla e trasforma. Il sito utilizza una rappresentazione già adatta alle proprie funzioni.
Questo approccio offre alcuni vantaggi:
- il sito può continuare a mostrare l'ultima versione valida se la sorgente è temporaneamente indisponibile;
- i dati possono essere verificati prima della pubblicazione;
- modifiche interne al gestionale non devono propagarsi direttamente al frontend;
- il formato web può evolvere senza intervenire sul sistema storico;
- gli errori possono essere isolati e registrati.
Non è soltanto un adattatore tecnico. È una zona di sicurezza tra sistemi con esigenze diverse.
Sincronizzare senza perdere il controllo
Una sincronizzazione automatica non dovrebbe essere una scatola nera.
È necessario sapere:
- quando è avvenuto l'ultimo passaggio;
- quanti elementi sono stati letti;
- quali sono stati modificati;
- quali record sono stati scartati;
- se il processo si è concluso correttamente;
- come ripeterlo senza creare duplicati.
Quest'ultimo punto è importante.
Le procedure devono essere idempotenti: eseguire nuovamente lo stesso import non dovrebbe produrre copie o risultati imprevedibili. Un prodotto deve essere riconosciuto attraverso un identificativo stabile e aggiornato, non ricreato ogni volta con entusiasmo.
Servono anche soglie e controlli.
Se un'esportazione che normalmente contiene migliaia di prodotti ne presenta improvvisamente dodici, forse non abbiamo appena assistito a una straordinaria razionalizzazione del catalogo. Forse il file è incompleto e non dovrebbe sostituire i dati pubblici.
Il CMS gestisce ciò che il gestionale non conosce
Il gestionale sa molte cose, ma non necessariamente sa raccontarle.
Può conoscere codice, descrizione amministrativa, prezzo e disponibilità. Il sito potrebbe aver bisogno anche di immagini, testi editoriali, categorie di navigazione, evidenze, documenti e contenuti pensati per il cliente.
Queste informazioni appartengono al CMS.
Il progetto deve quindi unire due tipi di contenuto:
- dati operativi, governati dal gestionale;
- dati editoriali, governati dal sito.
La chiave è evitare che uno sovrascriva accidentalmente l'altro.
Un aggiornamento automatico del prezzo non deve cancellare il testo scritto dall'ufficio marketing. Una modifica editoriale non deve trasformare il codice articolo su cui si basa la sincronizzazione.
Ogni campo deve avere un proprietario chiaro.
Il frontend nasconde la complessità
Per l'utente finale tutto questo dovrebbe essere invisibile.
Il cliente cerca un prodotto, consulta un listino o guarda un'offerta. Non deve sapere che alcune informazioni arrivano da un sistema COBOL, altre dal CMS e altre ancora vengono calcolate durante l'importazione.
La qualità del frontend consiste anche nel trasformare strutture tecniche in operazioni semplici:
- cercare con parole comprensibili;
- filtrare senza conoscere i codici interni;
- vedere informazioni coerenti;
- scaricare documenti corretti;
- capire quando un elemento è disponibile.
L'interfaccia non elimina la complessità. La assume e la organizza.
Il sistema storico non è il nemico
Nel mondo digitale esiste una forte attrazione per la sostituzione.
Nuovo framework, nuova piattaforma, nuovo gestionale, nuova architettura. Ripartire da zero offre una sensazione di ordine che i sistemi reali raramente possiedono.
Ma ciò che chiamiamo legacy è spesso il luogo in cui vive il lavoro dell'azienda.
Un software storico può avere limiti evidenti e, allo stesso tempo, contenere regole estremamente preziose. Sostituirlo senza comprenderle significa scoprire quelle regole una alla volta, normalmente dopo averle violate.
Integrare può essere una scelta più prudente e più moderna della riscrittura totale.
Moderna non significa usare soltanto tecnologie recenti. Significa costruire un sistema capace di evolvere senza distruggere ciò che già funziona.
Le epoche possono collaborare
Il progetto non consisteva nel convincere il COBOL a diventare un'applicazione web.
Consisteva nel definire un confine chiaro: il gestionale continuava a governare i dati aziendali; il nuovo sistema li trasformava e li rendeva utilizzabili online.
Da una parte un software costruito per processi interni. Dall'altra un'interfaccia pensata per persone, browser e dispositivi diversi.
In mezzo, la parte decisiva: regole di scambio, controlli, trasformazioni e gestione degli errori.
È un lavoro che difficilmente si nota guardando la homepage.
Ma è il motivo per cui ciò che appare sulla homepage può essere corretto.
La tecnologia cambia rapidamente. I dati e i processi aziendali molto meno.
Un buon progetto non obbliga necessariamente il passato a scomparire.
Gli insegna a parlare con il presente.