Per molto tempo abbiamo trattato il sito aziendale come una specie di isola turistica.
Un luogo ordinato, possibilmente gradevole, dove esporre chi siamo, cosa facciamo e come contattarci. Ogni tanto qualcuno prendeva una barca, raggiungeva l'isola, guardava due pagine e mandava un'email.
Nel frattempo, sulla terraferma, l'azienda lavorava con gestionali, fogli Excel, database, listini, cataloghi, CRM, software di produzione e procedure interne. Sistemi spesso molto più importanti del sito, ma completamente separati da esso.
Il risultato era che le stesse informazioni venivano gestite più volte.
Il prezzo veniva aggiornato nel gestionale e poi modificato nel sito. Il catalogo veniva esportato in Excel e poi reinserito nel CMS. Un documento cambiava sul server aziendale, ma online restava la versione precedente. Una persona si occupava dei dati reali e un'altra della loro rappresentazione pubblica.
Tutto funzionava finché qualcuno si ricordava di fare ogni passaggio.
I problemi, come spesso accade, cominciavano durante le ferie.
Il sito è un'interfaccia sui dati
Un sito moderno non dovrebbe essere pensato soltanto come un insieme di pagine.
Molto spesso è un'interfaccia che rende comprensibili e utilizzabili dati provenienti da sistemi diversi.
Un catalogo prodotti, per esempio, potrebbe mostrare:
- anagrafiche provenienti dal gestionale;
- immagini e testi gestiti dal CMS;
- disponibilità lette da un database;
- documenti tecnici archiviati su un server;
- prezzi diversi in base al cliente;
- traduzioni curate dall'ufficio marketing;
- dati aggiornati da fornitori esterni.
La pagina che vediamo nel browser è soltanto il punto in cui tutte queste informazioni si incontrano.
Se progetto soltanto la pagina, vedo l'ultimo metro del sistema. Se progetto il flusso dei dati, vedo il progetto intero.
Prima domanda: qual è la fonte corretta?
Quando la stessa informazione esiste in più posti, prima o poi le versioni divergono.
Il sito dice che un prodotto è disponibile, il gestionale dice il contrario e il commerciale possiede un foglio Excel secondo cui quel prodotto ha cambiato nome tre mesi fa.
Non serve necessariamente costruire un unico enorme sistema che controlli tutto. Serve stabilire, per ogni dato, quale sia la fonte autorevole.
Il gestionale potrebbe essere la fonte per codici, prezzi e disponibilità. Il CMS per testi, immagini e contenuti editoriali. Un servizio esterno per le spedizioni. Un database dedicato per gli utenti registrati.
Una volta definita la responsabilità, il sito può leggere il dato senza costringere qualcuno a copiarlo manualmente.
È una decisione architetturale, ma produce un effetto molto concreto: meno lavoro ripetuto e meno possibilità di errore.
Integrare non significa collegare tutto in tempo reale
Quando si parla di integrazioni si immagina spesso una rete sofisticata di API che scambiano informazioni in ogni istante.
A volte è la soluzione giusta. Altre volte è un modo costoso per rendere fragile qualcosa di semplice.
Un'integrazione può funzionare in molti modi:
- chiamate API in tempo reale;
- sincronizzazioni programmate;
- importazioni di file CSV, XML o JSON;
- lettura diretta da un database;
- code di messaggi;
- esportazioni generate dal gestionale;
- procedure manuali controllate, quando il volume non giustifica altro.
La scelta dipende da frequenza, quantità dei dati, affidabilità delle sorgenti e conseguenze di un eventuale ritardo.
La disponibilità di un prodotto può richiedere aggiornamenti molto frequenti. La biografia del fondatore probabilmente no.
Il tempo reale non è un valore morale. È un requisito, e come tutti i requisiti va dimostrato.
I sistemi vecchi non sono necessariamente sistemi sbagliati
Molte aziende possiedono software sviluppati anni fa che continuano a svolgere perfettamente il proprio compito.
Non hanno API moderne, interfacce eleganti o nomi rassicuranti. Producono magari file a intervalli regolari oppure lavorano su database che nessuno vuole esporre direttamente a Internet.
La tentazione è proporre di sostituire tutto.
È una tentazione comprensibile, soprattutto se la sostituzione viene fatturata da noi.
Ma un sistema storico contiene spesso anni di regole, eccezioni e conoscenza aziendale. Ricostruirlo non significa soltanto riscrivere il codice: significa scoprire lentamente tutto ciò che il vecchio software sapeva e che nessuno aveva mai pensato di documentare.
In molti casi è più sensato costruire un livello di comunicazione.
Il gestionale continua a fare ciò che sa fare. Un processo estrae i dati necessari, li controlla, li trasforma e li rende disponibili al sito. Il web diventa un nuovo punto di accesso, non un'invasione ostile del sistema informativo.
Trasformare è diverso da trasferire
Portare un dato dal gestionale al sito non significa necessariamente copiarlo così com'è.
I sistemi interni sono costruiti per chi conosce l'azienda. Usano codici, abbreviazioni, strutture e convenzioni che possono essere perfettamente sensate per l'amministrazione e completamente incomprensibili per un cliente.
Tra la sorgente e il sito serve spesso uno strato di trasformazione:
- normalizzare formati e unità;
- associare codici interni a nomi leggibili;
- unire informazioni provenienti da tabelle diverse;
- escludere dati che non devono essere pubblicati;
- controllare valori mancanti o incoerenti;
- creare relazioni utili alla navigazione;
- memorizzare una copia sicura per non dipendere sempre dalla sorgente.
Questo strato contiene una parte importante del valore del progetto. È il punto in cui i dati aziendali diventano informazioni utilizzabili.
Bisogna progettare anche i fallimenti
Ogni integrazione prima o poi smette temporaneamente di funzionare.
Un'API non risponde. Un file arriva incompleto. Una password scade. Il formato cambia senza preavviso. Una procedura pianificata decide di scioperare alle tre di notte, quando nessuno la sta guardando.
La domanda non è se accadrà, ma cosa farà il sistema quando accadrà.
Un progetto affidabile deve prevedere:
- log comprensibili;
- notifiche sugli errori;
- tentativi automatici controllati;
- validazione prima della pubblicazione;
- possibilità di tornare all'ultima versione corretta;
- strumenti per avviare nuovamente una sincronizzazione;
- separazione tra errori tecnici e dati realmente assenti.
Mostrare una pagina vuota perché il gestionale è momentaneamente irraggiungibile non è integrazione. È dipendenza senza precauzioni.
Il CMS rimane importante, ma cambia ruolo
Quando il sito dialoga con sistemi esterni, il CMS non scompare.
Smette però di essere il posto in cui duplicare ogni informazione.
Può gestire ciò che richiede giudizio editoriale: testi, immagini, priorità, traduzioni, approfondimenti, collegamenti e contenuti speciali. I dati operativi rimangono invece nella sorgente più adatta.
Il backend dovrebbe rendere evidente questa distinzione. Chi lo usa deve sapere quali informazioni può modificare, quali arrivano automaticamente e quando sono state aggiornate.
Altrimenti l'automazione produce soltanto una nuova forma di confusione, più veloce della precedente.
Il vero progetto è il flusso
Una homepage può durare alcuni anni prima di essere ridisegnata. Un flusso dati ben progettato può sostenere molte versioni diverse del sito.
È per questo che considero le integrazioni una parte del design.
Non riguardano soltanto server e codice. Determinano quali informazioni sono disponibili, quanto sono affidabili, chi può modificarle e che cosa succede quando qualcosa va storto.
Il sito smette così di essere un'isola aggiornata occasionalmente da qualcuno che porta notizie dalla terraferma.
Diventa una parte reale del sistema aziendale.
E quando il progetto funziona bene, nessuno pensa alle API, ai file importati o alle procedure automatiche.
Le informazioni sono semplicemente corrette.
Che è uno dei risultati tecnici più difficili da ottenere e uno dei meno spettacolari da mostrare in una riunione.