Negli articoli precedenti sono stati trattati la comunicazione come base per la interoperabilità e l’interazione tra umano e macchina attraverso l’interfaccia uomo-macchina . Nel suo articolo Anna Pompilio ha introdotto magistralmente i concetti di interoperabilità fra sistemi informatici sanitari e nel contesto della PA .
In questo articolo analizzeremo i dettagli di cosa c’è “dietro” tutto questo: come, in pratica, sistemi digitali distinti comunicano fra loro, ovvero come sono fatte le interfacce macchina-macchina, e le problematiche legate ad una loro progettazione e gestione.
Comunicazione digitale
È (quasi) universalmente noto che computer, smartphone, TV digitali, dispositivi IoT ecc… rappresentano al loro interno le informazioni in forma di bit. Ma cosa significa questo, in pratica?
Il singolo numero binario o bit (contrazione da BInary digiT) è una cifra espressa in base due e quindi può assumere solo i valori 0 e 1. Quindi ad esso possono essere associati solo due elementi, ovvero una informazione (o meglio un dato) a due valori possibili. Per esempio, positivo/negativo, bianco/nero, rosso/verde, caldo/freddo ecc… Pertanto, da solo, un bit ha una utilità limitata.
Se mettiamo insieme due cifre binarie, ovvero componiamo un numero binario a due cifre, i valori possibili sono 4 (00, 01, 10, 11). Se componiamo un numero a tre cifre, i valori possibili sono 8. E così via, secondo la regola: Valori possibili date N cifre = 2 elevato a N-sima potenza.
In particolare se prendiamo numeri binari ad 8 cifre, i valori possibili diventano 256 (per la precisione, con valori da 0 a 255) e quindi, attraverso opportune tabelle di codifica che rappresentano la meta-informazione, ossia le regole che danno un significato ai byte , diventa possibile rappresentare:
- testo (il più diffuso standard è il codice ASCII),
- immagini a toni di grigio dove ogni byte rappresenta un pixel (ad esempio, 0 è il nero e 255 è il bianco con tutte le sfumature in mezzo),
- suoni (con una qualità molto bassa in verità, infatti servono almeno 2 byte per rappresentare un singolo campione sonoro di qualità ed un flusso di 44.100 campioni al secondo per avere la qualità del CD),
- temperature, e molto altro.
Un insieme di 8 bit si chiama byte ed è l’unità di misura della memoria RAM e della memoria di massa (hard disk, schede di memoria, chiavette usb…) in tutti i dispositivi digitali, eventualmente attraverso i suoi multipli come il kilobyte, il megabyte, il gigabyte ed il terabyte.
I dispositivi digitali moderni rappresentano quindi numeri, come i dati di un bilancio aziendale, le temperature di una città, ma anche immagini, suoni, filmati, testi, documenti ecc… come insiemi di byte. In questo modo, con opportuni formati digitali, queste informazioni sono memorizzate in forma di insiemi di file e di archivi strutturati come i database relazionali.
Il problema della codifica esiste anche nella comunicazione. I primi sistemi di comunicazione fra dispositivi digitali (computer, a partire dagli anni ’50 e ’60) erano completamente proprietari, ossia tutto quanto serviva alla comunicazione, dalla rappresentazione dei dati sotto forma di byte, alla loro traduzione in segnali fisici (ad esempio, impulsi elettrici), alla stessa struttura dei canali fisici (ad esempio, caratteristiche elettriche e materiali dei cavi, come impedenze, forma degli spinotti ecc…) era stabilito da regole tipiche di ogni costruttore, o di consorzi di ricerca. Non esisteva uno standard comune, che consentisse ad un sistema, per esempio, di IBM, di dialogare con un sistema di HP.
Solo nel tempo si arrivò a creare uno standard comune di comunicazione, chiamato TCP/IP, alla base di quella che oggi è Internet . Questo insieme di protocolli di comunicazione, che consente a qualsiasi dispositivo digitale, collegato alla rete attraverso tantissimi tipi di canali fisici diversi (ad esempio, cavo ethernet, wifi, doppino telefonico, fibra ottica…), di scambiare flussi ordinati di byte (quindi file e simili) con qualsiasi altro, ha reso possibile la trasformazione digitale .
Le diverse lingue digitali e le conseguenti problematiche
Siamo quindi a posto? Basta Internet col TCP/IP per tutto? Purtroppo no, perché questo standard rende possibile, da solo, solamente lo scambio di file e flussi di byte. Quindi funziona come un efficacissimo sistema postale in grado di trasportare “buste digitali” praticamente in tempo reale in tutto il mondo. Il contenuto dei messaggi (file e altro) e quindi la conversazione digitale su di essi basata è da definire a parte, caso per caso.
Per esempio, dato che non tutti i computer usano lo standard ASCII per rappresentare il testo, se devo trasferire un file di testo (o anche solo dei comandi per il computer espressi come testo, quando si usa una interfaccia a riga comandi ) questo dovrà essere convertito dal formato del computer mittente a quello del computer destinatario, per dare un senso alla comunicazione.
Se passiamo a dati complessi, come, per esempio, una fattura, da trasmettere all’interno di un apposito processo di pagamento, basato su una successione di scambi di messaggi equivalente a quelle che era il processo “cartaceo”, occorre definire chiaramente cosa esprime la fattura. Per molti anni infatti il processo è stato solo dematerializzato, attraverso la spedizione della fattura in un formato visibile per gli esseri umani come il PDF.
Il processo “fatturazione” quindi si poteva tradurre in questa sequenza:
- Un operatore umano, interagendo con un programma di fatturazione, inserisce i dati e genera la fattura in formato PDF;
- L’operatore salva la fattura come file e lo spedisce via posta elettronica al destinatario;
- Un altro operatore umano riceve il messaggio di posta elettronica, ne estrae la fattura e:
– se abituato a “fare tutto in elettronico” inserisce, magari con il copia-e-incolla, i dati della fattura nel programma di gestione contabile e, probabilmente, anche nel sistema di home banking per gestire il pagamento;
– se non abituato, stampa la fattura (con conseguente spreco di tempo, carta, spazio di immagazzinamento ecc…) e fa le operazioni suddette, o magari passa la fattura cartacea ad un/una collega perché le svolga;
– se gli accordi lo prevedono manda una stampa elettronica (tipicamente in PDF) con gli estremi del pagamento al creditore.
Che valore aggiungono al processo questi interventi umani? Nessuno. Anzi, aggiungono invece dei rischi (ad esempio, errori di battitura durante l’inserimento manuale dei dati). Alcuni esperti di gestione aziendale addirittura li definiscono “attività parassitiche”.
Un processo completamente digitale prevede che il flusso avvenga direttamente fra i programmi di contabilità. E che, quindi, nei messaggi siano contenuti i dati della fattura espressi in un formato comprensibile a tutti gli attori coinvolti nella comunicazione. E che si possa, eventualmente, fare riferimento a documenti precedentemente scambiati come offerte, bolle ecc… per validare i dati della fattura stessa. Questo indipendentemente dai programmi utilizzati. Quanto la cosa sia stata “leggermente complicata” lo sanno bene tutti coloro che negli anni scorsi sono stati investiti dalla nuova legge sulla fatturazione elettronica.
Se, poi, consideriamo processi più complessi di una fatturazione ecco per esempio gli scenari presentati in .
Le regole per il dialogo
Quindi perché un processo possa essere completamente digitale è necessario che tutte le informazioni siano completamente comprensibili sia alla sorgente sia alla destinazione, sino al livello ultimo di significato dei byte e che quindi vi sia una completa condivisione dei formati di rappresentazione dei dati fra le parti.
Oltre a questo, il processo di interscambio dei dati fra sistemi digitali deve seguire regole precise, deve essere quindi una successione ordinata di messaggi in un verso e nell’altro lungo il canale di comunicazione, come una conversazione (molto) formale tra esseri umani. È fondamentale ricordare che le macchine non hanno la flessibilità degli esseri umani. Se le regole di scambio messaggi non prevedono una determinata situazione, questa sarà segnalata come errore e, a meno che non sia stata prevista una adeguata procedura di gestione di tale errore, la comunicazione fallirà.
Vediamo un esempio specifico, supponendo di definire un dialogo per l’interoperabilità fra un dispositivo digitale che misura parametri ambientali (temperatura, umidità, pressione atmosferica…) e una centralina di raccolta che raccoglie i dati da tanti sensori.
Come rappresentato in modo molto semplificato nel dialogo, occorre una autenticazione per iniziare la comunicazione e stabilire chi sono le parti, una rappresentazione digitale di formato condiviso per i dati trasmessi, una eventuale verifica dei dati trasmessi e ricevuti (si ricordi, come spiegato in , che il canale non è ideale e può condurre ad errori) ed una regola per la chiusura della comunicazione.
Se il sensore e la centralina, che magari sono stati fabbricati da fornitori diversi, non seguono esattamente il protocollo di comunicazione, questa non potrà avere luogo e quindi i due sistemi non saranno interoperabili.
Poi è necessario che ci siano altre meta-informazioni e che, ad esempio, la centralina, che probabilmente è un computer in Cloud, magari anche collocato in un data center fuori dai confini dell’Italia, “sappia” che il sensore 101 si trova in Piazza Garibaldi a Parma e che, quindi, i parametri ambientali ricevuti si riferiscono a tale località.
Tipologie di comunicazione macchina-macchina
Come avviene allora la comunicazione fra macchine in generale? Occorre fare una distinzione fra:
- Comunicazioni “in tempo reale”, come ad esempio quelle che avvengono fra una app in uno smartphone e i server di un sistema di car sharing; queste possono poi essere ulteriormente suddivise fra
– o Sincrone: il mittente invia il messaggio e resta in attesa della risposta, non proseguendo in altre attività,
– o Asincrone: il mittente invia il messaggio e poi prosegue con altre attività, la risposta del destinatario (se prevista) sarà inviata in un momento successivo; - Comunicazioni “in differita”: non esiste un vincolo temporale stretto e i dati possono essere trasmessi tramite sistemi di code (come per esempio e-mail o messaggistica istantanea); in questo caso la comunicazione può essere monodirezionale oppure vi può essere una risposta, normalmente gestita in modo asincrono.
Le comunicazioni in tempo reale sono gestite con protocolli diretti di scambio messaggi fra le parti, come, ad esempio, http (usato originariamente solo per i siti web), mentre le altre si appoggiano normalmente su sistemi per l’interscambio di file e messaggi basati su code (il primo che arriva è il primo ad essere spedito).
Nel primo caso chi progetta il sistema dovrà definire la struttura del dialogo (come nell’esempio della figura) e la sintassi ed il contenuto di ogni singolo messaggio, o implementare standard che descrivano tutto, se esistono. Nel secondo invece la gestione flusso potrà essere assegnata a sistemi preesistenti di scambio file e sarà invece necessario definire il formato del contenuto di ogni file ed il suo significato entro il processo (come nel caso della fatturazione elettronica).
Il rischio spaghetti-integration e la necessità di regole
Oggi, con il moltiplicarsi del numero dei device e con la implementazione di passaggi complessi, che coinvolgono molteplici sistemi connessi fra loro con combinazioni di comunicazioni in tempo reale ed in differita, è diventato necessario imporre delle regole. Infatti, per molto tempo, l’approccio progettuale è stato quello di costruire una interfaccia di comunicazione digitale specifica fra due sistemi ogni volta che ne emergesse la necessità. E questo, se N sono i sistemi da collegare, ci può portare a avere N per N-1 / 2 interfacce di comunicazione, da realizzare e gestire!
Per fare un paragone con il mondo fisco, è come, dati tutti i comuni della provincia di Parma, noi volessimo realizzare una strada specifica che colleghi ogni comune con ogni altro comune della provincia.
Questo approccio, definito in come architettura incidentale e, come ulteriore degenerazione, spaghetti-integration, ha condotto al caos di numerosi sistemi informatici, facendo crescere enormemente le spese di gestione e aumentando la fragilità dei sistemi stessi. Infatti, se un processo aziendale richiede una comunicazione che attraversa tante interfacce , basta che una sola di queste abbia un malfunzionamento per bloccare tutta la comunicazione.
E, se è vero in un sistema informatico interno ad un’azienda, a maggior ragione è vero quando si passa nel mondo odierno, dove i sistemi sono in parte interni ad un’azienda, in parte nel cloud e alcune operazioni obbligatorie per legge, come la fatturazione elettronica, passano per sistemi statali centralizzati.
E, quindi, un processo che per l’utente sembra apparentemente semplice, come per esempio prenotare un’auto in car sharing e aprirla mediante l’app, pagando poi alla riconsegna quanto dovuto, sempre tramite l’app, comprende invece una complessa interazione fra sistemi diversi, appartenenti ad aziende e pubbliche amministrazioni diverse, magari posti anche in nazioni o in continenti diversi.
E, soprattutto, man mano che prosegue la trasformazione digitale queste complesse interazioni fra sistemi diventano sempre più indispensabili per il funzionamento della nostra società. E come hanno dimostrato i casi degli ultimi mesi, fattori ambientali come le epidemie e attacchi informatici li rendono estremamente vulnerabili.
È necessario quindi un insieme di regole da seguire per ridurre rischi legati a loro malfunzionamenti sin dalla progettazione, come del resto richiesto da leggi come il GDPR e la direttiva NIS .
Bibliografia
Giulio Destri – Interoperabilità: lo scambio di informazioni come luogo di inter-mediazione e comunanza
Giulio Destri – L’interfaccia utente: il luogo visibile delle relazioni – spesso invisibili – tra l’Uomo e la macchina
Anna Pompilio – L’insostenibile leggerezza dell’Essere Interoperabile
Giulio Destri – Introduzione alle Comunicazioni in Rete
Giulio Destri – La Digital Transformation: luci ed ombre del cambiamento
David Chappell – Enterprise Service Bus: Theory in Practice
Giulio Destri – Sistemi Informativi il pilastro digitale di servizi ed organizzazioni – Ed. Franco Angeli 2013
Giulio Destri – GDPR e IT Service Management: la progettazione dei nuovi servizi IT nel rispetto della normativa
Agendadigitale – Direttiva NIS, così è l’attuazione italiana (dopo il recepimento): i punti principali del decreto
CREDITS IMMAGINI Immagine di copertina (rielaborata): ID Immagine: 90445295. Diritto d'autore: Kheng Ho Toh ID Immagine: 88979881. Diritto d'autore: Milosh Kojadinovich
