Chi ha bisogno di un gateway API?

Le API (Application Programming Interface) sono la base e il cuore dell’interoperabilità fra sistemi informatici, cioè della capacità dei sistemi di scambiarsi dati o condividere funzioni. L’interoperabilità è un’esigenza sempre più sentita anche nel mondo della pubblica amministrazione e nel recente passato ha trovato nuovo slancio grazie all’avvento della PDND (Piattaforma Digitale Nazionale Dati) che, a lungo attesa, abilita l’interoperabilità sicura, pur senza inventare niente di particolarmente nuovo dal punto di vista informatico.

Il mondo interoperabile prevede, come elementi base: un soggetto erogatore che mette a disposizione di un soggetto fruitore un servizio digitale con il quale si interagisce tramite l’interfaccia API. Il servizio digitale consente di leggere o trasferire dati nel sistema dell’erogatore oppure di sfruttare funzioni applicative o di calcolo del soggetto erogatore e beneficiare dei risultati.

API: cos’è

Semplificando, l’API è un linguaggio astratto, che prescinde dagli interlocutori coinvolti, tramite il quale si può formulare una richiesta a un sistema remoto, disinteressandosi del funzionamento del sistema stesso. Allo stesso modo il sistema interrogato risponde nel linguaggio stabilito dalla API, indipendentemente dal funzionamento del sistema che ha fatto la richiesta e dei successivi usi che questo farà della risposta ottenuta.

Tale impostazione genera vantaggi per tutte le parti coinvolte.

I vantaggi per il fruitore

Il fruitore che ha bisogno di un dato si disinteressa totalmente di come l’erogatore ha organizzato la sua banca dati ma esprime in modo sintetico un’esigenza, secondo il linguaggio convenzionale stabilito dal documento di specifiche della API. Per esempio, se il fruitore vuole conoscere l’indirizzo di una persona individuata tramite codice fiscale o altro codice identificativo, non ha bisogno di sapere se l’erogatore che detiene l’informazione ha associato il dato dell’indirizzo direttamente alla persona, alla sua famiglia o all’abitazione occupata dalla famiglia. E’ il sistema dell’erogatore che prende in carico la richiesta e, conoscendo il modello dati implementato nel suo sistema, fa le ricerche (query) opportune e restituisce la risposta.

I vantaggi per l’erogatore

Allo stesso modo l’erogatore che si è assunto l’onere di fornire risposte ai fruitori è libero di riorganizzare i propri dati, aggiornare le modalità con cui effettua le ricerche, modificare il funzionamento applicativo dei propri sistemi senza mettere a rischio il dialogo con i fruitori. L’unico vincolo è, appunto, mantenere la capacità di rispondere alle richieste dei fruitori (che arriveranno nella stessa immutata forma) e riprogrammare il “motore” che fornisce ai fruitori le risposte (che dovranno mantenere la stessa immutata forma anch’esse).

Disaccoppiamento fra back-end e front-end

A un livello più tecnico e generale, si può dire che tramite le API si riesce a disaccoppiare la componente di front-end, cioè quella che consente di fruire materialmente di dati o funzioni, da quella di back-end, cioè quella che fa il lavoro nascosto di gestione dei dati, interrogazioni, calcolo ecc.

Il disaccoppiamento vale anche per sistemi tutti sotto il controllo di uno stesso soggetto che, in qualche misura, è erogatore nel momento in cui gestisce il back-end ed è fruitore quando deve restituire dati o consentire di fare operazioni tramite un’interfaccia utente (il front-end).

Quindi, in linea teorica, si può cambiare l’esperienza utente e modificare l’interfaccia d’uso di uno strumento informatico senza andare a toccare il funzionamento intimo del sistema o, viceversa, si può mantenere immutata l’interfaccia grafica e le modalità d’uso e migliorare il funzionamento interno di un sistema, per esempio per rendere più veloci ricerche in banche dati voluminose. O ancora, si può consentire a più interfacce utente di fare operazioni su uno stesso sistema con lo stesso risultato: sarebbe il caso auspicabile in cui, in una pubblica amministrazione, si protocolla un documento a partire dal sistema che lo ha generato, senza bisogno di aprire un’altra interfaccia, immettere nuovamente dati e trasferire file.

Chi espone l’interfaccia API?

Per far funzionare il dialogo interoperabile via API occorre che il sistema dell’erogatore si doti di componenti informatici accessori specifici (i cosiddetti e-service, o servizi digitali), che possiamo pensare come delle porte che restano in attesa che qualcuno vi si affacci con un messaggio di richiesta e che poi, sulla base di diversi possibili flussi di interazione, forniscano immediatamente una risposta, la rendano disponibile successivamente o si facciano carico di inviarla, proattivamente, in seguito, ai sistemi del fruitore (che a sua volta avrà quindi una porta che resta in attesa di messaggi).

Dalla parte del fruitore, dualmente, occorre sviluppare dei connettori, cioè delle componenti in grado di dialogare con l’e-service dell’erogatore, farsi riconoscere, formulare richieste, recepire le risposte.

Tecnicamente gli e-service che espongono l’interfaccia API e i connettori possono essere implementati in due modi distinti:

• direttamente integrati nella componente informatica del sistema che mette in condivisione o dati o funzioni applicative o che chiede di accedervi a un sistema remoto, in uno schema secondo il quale ogni componente del sistema informativo sviluppa e implementa un “pezzo” aggiuntivo che sovrintende agli scambi interoperabili;
• in modo centralizzato, tramite un gateway API, che fa da collettore per le comunicazioni API in arrivo o in partenza. Il gateway API resta quindi in ascolto e, quando serve, si fa carico di dirottare una richiesta in arrivo al sistema che può fornire la risposta (anche traducendola in un altro linguaggio) o di veicolare verso l’esterno una richiesta generata all’interno del sistema informativo (anche in questo caso traducendola nel linguaggio della API esposta dal sistema remoto).

Non esiste in assoluto un modo migliore dell’altro per gestire la comunicazione interoperabile, dipende dal contesto, dal numero di sistemi da mettere in comunicazione, dalle risorse a disposizione ecc. Entrambe le impostazioni, comunque, hanno pro e contro.

Usare un gateway API ha l’evidente vantaggio che solo il gateway resta accessibile dal mondo esterno e questo favorisce la sicurezza del sistema informativo, perché dovrebbe essere più semplice stabilire canali sicuri fra server interni e gateway API e mantenerli sicuri nel tempo, piuttosto che aprire i server interni ad accessi diretti dall’esterno ed esporli al rischio che qualche malintenzionato sfrutti qualche vulnerabilità o debolezza. Poi, certamente, non che il gateway da solo renda tutto sicuro, ma razionalizza i flussi di dati e minimizza la cosiddetta superficie d’attacco.

Allo stesso tempo il gateway API ha lo svantaggio che aumenta la complessità del sistema informativo, o, almeno, il numero delle componenti in cui si articola.

La scelta se dotarsi o meno di un gateway API, dunque, va ponderata sulla base del rapporto fra costi e benefici, rapporto che può essere valutato solo conoscendo il contesto tecnologico e organizzativo. Nel seguito si tenterà, dunque, di fornire qualche elemento per “ponderare”.

Alcuni dubbi (ricorrenti)

A rischio di deludere chi si attende di trovare risposte perentorie, specifico che qui si intende condividere, quasi in un ragionamento fatto ad alta voce, alcune di quelle considerazioni e di quei dubbi che attanagliano chi si occupa di trasformazione digitale in un contesto di pubblica amministrazione.

Per quanto riguarda l’interoperabilità e la PDND, chi si occupa di trasformazione digitale si trova adesso a fare i conti con esigenze e obblighi normativi di condivisione di dati, nella duplice veste di erogatore e fruitore. Alcune domande che sorgono spontanee sono:

• dove sono i dati che mi si chiede di condividere?
• a quali dati altrui sarebbe utile accedere?
• ho bisogno di un gateway API?
• ne ho bisogno solo se sono erogatore?
• chi lo gestisce?
• quale strada è economicamente più sostenibile?
• quale strada è tecnicamente più sostenibile?

L’intento non è fornire risposte definitive che, ragionevolmente, non esistono replicabili in qualsiasi contesto tecnologico e operativo, ma solo offrire qualche spunto per le inevitabili considerazioni personali che guidano quelle scelte che, in un momento che non a caso diciamo di transizione digitale, non sono mai scontate^[1]Alla faccia di chi dice che la trasformazione digitale non è un problema tecnico. Problemi tecnici, ahinoi, se ne presentano a bizzeffe….

ll Gateway API (o API Manager): cos’è e cosa fa

Il gateway API, come dice il nome, “si mette in mezzo” a tutte le comunicazioni interoperabili (in entrata e in uscita) del sistema informativo in cui è collocato e, poiché tutte le interazioni lo attraversano, si realizzano almeno due situazioni rilevanti dal punto di vista funzionale:

• il gateway ha la visione d’insieme, anche quantitativa sulle interazioni in entrata e in uscita;
• il gateway può intervenire sui messaggi scambiati, per esempio trasformandone la sintassi in una più conforme alle attese del destinatario del messaggio stesso.

In un sistema informativo dotato di un gateway API, quindi, tutte le componenti che sono coinvolte in interazioni interoperabili, dialogano con il mondo esterno tramite l’intermediazione del gateway stesso e sono collegate direttamente solo a questo.

Per tradurre la situazione teorica in casi pratici, se facciamo riferimento all’interoperabilità come è indirizzata dal funzionamento della PDND e, più in generale, dai pattern di sicurezza e interazione definiti nel ModI (il modello di interoperabilità tecnica nazionale), un gateway API può farsi carico e centralizzare alcuni compiti che, diversamente, dovrebbero essere replicati in ogni componente che espone servizi digitali in proprio. Nel seguito ne vediamo alcuni, cercando di individuare le differenze fra gestione centralizzata tramite gateway API e gestione autonoma a cura di ogni componente del sistema informativo.

Volumi di traffico

Il gateway può farsi carico di contare le chiamate a un dato servizio. Come si osserva, uno degli attributi principali dei servizi digitali pubblicati sulla PDND (e delle API in genere), è il volume massimo di chiamate consentito al giorno sia a livello globale sia a livello di singolo fruitore. La ragione del limite di chiamate è evidente, ma giova ricordarla: dal punto di vista dell’erogatore rispondere a una richiesta è un costo, almeno in termini di risorse informatiche (computazionali) del suo sistema. Le risorse non sono illimitate e quindi l’erogatore riesce a far fronte solo a un certo numero di richieste.

Contare le interazioni diventa quindi essenziale. Lo è senz’altro dal punto di vista dell’erogatore che, in realtà, potrebbe farlo anche a livello di componente che riceve materialmente la richiesta, a meno che non abbia un sistema particolarmente articolato per cui richieste dello stesso tipo sono prese in carico e distribuite fra più componenti che elaborano la risposta, così da bilanciare i carichi di lavoro.

In realtà, centralizzare il conteggio delle chiamate API diventa utile anche per il fruitore. Infatti, il fruitore potrebbe utilizzare lo stesso servizio digitale pubblicato su PDND a partire da componenti distinte per scopi diversi. Per esempio, in un comune, si interroga ANPR (l’Anagrafe Nazionale della Popolazione Residente) sia per gli scopi dell’ufficio tributi sia per quelli di polizia locale, ragionevolmente a partire da strumenti informatici distinti. Ecco, in questi casi, le strade per evitare che un ufficio finisca tutte le interazioni e interferisca con il funzionamento dell’altro sono almeno due:

• sulla PDND si definiscono due finalità distinte, una per ufficio, ciascuna con una sua previsione di chiamate giornaliere così da rendere le interazioni del tutto indipendenti (forse, v. avanti);
• si crea un’unica finalità e si gestisce la distribuzione delle chiamate internamente, tramite l’API gateway, che può adottare logiche più o meno sofisticate per distribuire il traffico disponibile (non tutti i giorni sono uguali, del resto).

Entrambi gli scenari hanno pro e contro: due finalità distinte, tutto sommato, consentono di definire meglio anche gli aspetti amministrativi e di protezione dei dati personali; gestire i carichi internamente, invece, evita di “prenotare risorse eccessive” sul sistema dell’erogatore, perché, appunto, non tutti i giorni si raggiunge il limite di chiamate in tutti gli uffici interessati.

Un requisito “nascosto” delle specifiche API di ANPR

Contare globalmente le chiamate da parte del fruitore, in realtà, potrebbe essere necessario anche indipendentemente da questioni di traffico, perché fondamentale proprio per fruire del servizio stesso.

Se andiamo ad analizzare le specifiche API dei servizi digitali esposti da ANPR^[2]MI riferisco proprio al file di specifiche in formato OpenAPI, disponibile solo su PDND dopo autenticazione. al di là della documentazione tecnica testuale liberamente disponibile sul sito di ANPR (per esempio qui), si scopre che uno dei dati da passare obbligatoriamente nelle richieste ad ANPR è il valore di “idOperazioneClient” che deve essere una stringa (numerica) ed ha questo significato:

idOperazioneClient*

string Identificativo univoco attribuito all’operazione dall’ente. Deve essere numerico e crescente. Se esiste in ANPR, l’ente riceve come esito la risposta in precedenza fornita da ANPR con lo stesso ID; se non esiste ed e’ inferiore all’ultimo inviato, l’elaborazione termina con errore.

Nello scenario più tipico un ente pubblico che reperisce sul mercato i software a supporto delle proprie funzioni istituzionali e lo fa, possibilmente, affidandosi a software erogati in modalità SaaS. In un SaaS il funzionamento tecnico è tutto sotto il controllo del fornitore e il software dovrebbe arrivare con a bordo l’integrazione con i servizi di ANPR e di altre banche dati di interesse nazionale. In che modo, allora gestire la necessità di contare a livello globale le operazioni?

Non è chiaro, in realtà, se ANPR effettui il controllo:

• a livello di ente, o, nella terminologia PDND, a livello di accordo di fruizione;
• a livello di funzione del fruitore in cui l’operazione si pone o, nella terminologia PDND, a livello di finalità;
• a livello di componente informatico del fruitore da cui origina la richiesta o, nella terminologia PDND, di client e-service^[3]Il client e-service, nella PDND, è il contenitore del materiale crittografico – in definitiva, della chiave pubblica – che PDND ed erogatore usano per decifrare alcune parti dei messaggi … Continue reading

In realtà, non è nemmeno chiaro se ANPR esegua proprio il controllo, ma, se lo scrive, è doveroso attenersi alle istruzioni.

Nel dubbio, non si possono dare indicazioni decisive. Tuttavia, se davvero il controllo fosse a livello di ente fruitore, le strade sembrerebbero due:

• centralizzare la gestione delle richieste tramite un gateway API e delegare a quello di riempire il valore della chiave “idOperazioneClient”;
• oppure, in modo un po’ grezzo, se non si usa un gateway, usare come “idOperazioneClient” un timestamp, magari seguito da un contatore delle chiamate fatte dalla singolo componente del sistema (in questo modo si garantisce la “crescenza” dell’identificativo numerico e si evitano collisioni – a meno di sfortunate chiamate nello stesso millesimo di secondo…).

Gestione dell’interoperabilità tecnica

Il ModI prevede che i messaggi scambiati fra fruitori ed erogatori abbiano delle caratteristiche tecniche di sicurezza, imposte dall’erogatore che le sceglie, auspicabilmente, fra le opzioni (pattern) definite dal ModI stesso.

Per esempio, ma non solo:

• le interazioni mediate dalla PDND prevedono che il fruitore, per autenticarsi sull’e-service, inserisca nell’intestazione delle sue richieste il cosiddetto “voucher” che deve ottenere ogni volta tramite la PDND. SI tratta di una stringa alfanumerica – tecnicamente un token JWT ottenuto secondo algoritmi informatici standard – che prescinde dal contenuto dei messaggi scambiati e dipende solo da dati depositati dal fruitore sulla PDND, quali l’identificativo della chiave pubblica per decifrare i messaggi, la finalità dell’interazione che si vuole avviare, il destinatario dell’interazione ecc. (oltre che dal tempo – infatti ha una validità temporale limitata);
• le interazioni interoperabili possono inoltre prevedere, a tutela della loro integrità e conferma della loro provenienza, la firma elettronica del contenuto dei messaggi scambiati: solitamente questi sono in formato XML o JSON e si firmano inserendo nell’intestazione delle chiamate l’hash (o digest) del messaggio stesso, cifrato con la chiava privata associata alla chiave pubblica (depositata su PDND).

Entrambe le operazioni possono essere gestite, dal punto di vista del fruitore, tramite un gateway API che le esegue prima di prima di attivare il dialogo vero e proprio con il servizio digitale dell’erogatore. La componente informatica che avvia la chiamata si limita, quindi, alla parte di contenuto vero e proprio della richiesta, mentre la parte di autenticazione e di garanzia di integrità è gestita dal gateway API. Quando poi si riceve la risposta, il gateway API libera il contenuto da eventuali cornici di sicurezza e lo trasmette, pronto per l’uso, a chi l’ha richiesto. Allo stesso modo, dal lato dell’erogatore, un gateway API riceve le richieste, verifica i requisiti di autenticazione del richiedente e di integrità del messaggio (appoggiandosi alla PDND) e trasmette le richiesta senza ulteriori orpelli alla componente informatica che deve elaborarla.

Le operazioni sopra descritte, naturalmente, possono essere gestite anche senza un gateway API, ma occorre implementare in ogni componente delle procedure che svolgono la stessa cosa.

Gestione dell’interoperabilità sintattica (e semantica)

L’aspetto fondamentale degli scambi interoperabili è la composizione sintattica del messaggio che l’erogatore rende nota tramite il documento di specifica API^[4]Il documento di specifica API è solitamente un file in formato OpenAPI (.yaml o JSON) o WSDL (basato su XML) e fornisce, in un linguaggio formale, le regole sintattiche per comporre i messaggi e … Continue reading. Nella maggior parte dei casi il contenuto (payload) degli scambi è a un documento in formato JSON o XML, nel quale i dati scambiati sono i valori delle chiavi o dei tag, composti in accordo con le specifiche. Poiché, come tristemente noto, non necessariamente le specifiche API, anche di uno stesso dominio applicativo o di conoscenza, si rifanno a un medesimo standard (che può anche non esistere), può darsi il caso che richiedere dati omogenei a fonti diverse richieda di comporre i messaggi di richiesta con sintassi diverse e, successivamente, elaborare risposte composte a loro volta con sintassi diverse.

La conversione dei messaggi di richiesta per adattarsi alle aspettative dell’erogatore può essere delegata al gateway API che, acquisita la specifica API dell’erogatore, mette a disposizione degli strumenti per “mappare” la struttura di dati richiesta dall’erogatore su quella che la componente informatica che avvia la richiesta è abituata a usare. La complessità dell’operazione, quindi, si può spostare su una componente informatica dedicata (il gateway API) e si mantiene la componente che esegue la chiamata specializzata sulle se funzioni originarie, senza appesantirla.

Condividere dati non gestiti in DB e sistemi strutturati

Spesso e volentieri le organizzazioni sono titolari di dati che sarebbe utile mettere in condivisione ma che, tuttavia, non sono contenuti in un sistema strutturato pronto per esporre un servizio digitale di interrogazione. Probabilmente, un gateway API può venire in soccorso anche in questi casi, collegandosi direttamente alla fonte di dati e mettendo a disposizione direttamente l’interfaccia API per l’interrogazione (dopo, ovviamente, la definizione di qualche regola).

Accedere a dati utili in processi non gestiti in modo strutturato

Così come le organizzazioni dispongono di dati non gestiti in sistemi strutturati, allo stesso modo possono avere bisogno di accedere a dati altrui mentre svolgono delle funzioni che non hanno a supporto uno strumento digitale (un software) capace di interfacciarsi, tramite API, con la banca dati di interesse.

In questi casi, la tentazione è quella di disporre di un’interfaccia di interrogazione manuale, una pagina web dove inserire le chiavi di ricerca per poi visualizzare (o scaricare) il risultato.

Ora, a voler fare i precisini, l’interoperabilità dei dati non è pensata esattamente per questo caso d’uso, perché altrimenti, per fare un esempio, ANPR piuttosto che dei servizi digitali pubblicati sulla PDND avrebbe reso disponibile un portale web al quale registrarsi per fare interrogazioni libere. La forza dell’interoperabilità dovrebbe invece essere quella di mostrare all’operatore di turno dati provenienti da fonti esterne, senza che questi nemmeno se ne accorga, in modo trasparente.

Non si tratta, in realtà, solo di una questione di esperienza d’uso. A ben vedere, vincolare l’accesso a dei dati all’uso di uno strumento digitale (software) che supporta il fruitore nello svolgimento di una sua funzione istituzionale ha senso. Infatti, è corretto concedere l’accesso solo a dati che effettivamente servono: se il fruitore sta conducendo una certa attività sui suoi sistemi, ragionevolmente ha un bisogno reale di accedere a quei dati. Tramite una maschera di interrogazione libera, invece, è possibile accedere arbitrariamente a qualsiasi dato. Poco importa se, nella maggior parte dei casi, le interrogazioni di un sistema remoto esigono, fra i dati della richiesta, anche il motivo della richiesta stessa.

Pragmaticamente, tuttavia, dove non ci sono software strutturati a supporto dei processi^[5]Il caso di funzioni svolte senza software strutturati a supporto si presenta eccome negli enti pubblici. Alcune attività, infatti, sono condotte semplicemente tramite scambio e consultazione di … Continue reading il “portale di interrogazione libera” è decisamente irrinunciabile.

Tecnicamente, è possibile utilizzare un servizio di consultazione di dati pubblicato sulla PDND, con i dovuti accorgimenti, anche a partire da una maschera di interrogazione da compilare manualmente, non integrata in un flusso di dati digitale. In linea di principio, poi, una volta allestita la cornice di funzionamento generale del software di interrogazione (autenticazione degli utenti, configurazione del collegamento con la PDND per ottenere i voucher, raccolta dei log ecc.), dovrebbe essere facile allestire una maschera di interrogazione a partire dal documento di specifica API messo a disposizione dall’erogatore.

Ecco, un gateway API potrebbe, come suo accessorio, mettere a disposizione anche un’interfaccia di interrogazione libera di qualsiasi servizio digitale presente sulla PDND.

Gateway API: sì o no?

Come preannunciato, quanto fin qui illustrato non fornisce un’indicazione certa sulla necessità o sull’utilità di dotarsi di un gateway API. Al solito, la scelta dipende da molti fattori.

Riguardo agli elementi da valutare per indirizzare la scelta, si può fornire qualche suggestione conclusiva, in ordine sparso:

• gestire un ulteriore componente è un onere, sia tecnico che economico;
• centralizzare le operazioni di comunicazione interoperabile tramite un gateway potrebbe collidere con la tendenza attuale di dotarsi di software erogati come servizi cloud SaaS (Software as a Service). In questo caso il fornitore del software, quando virtuoso, serve numerosi clienti con un’unica installazione del suo software e tende a fornire il pacchetto completo. Obbligare il fornitore a rendere il software SaaS interoperabile tramite i gateway dei singoli clienti sembrerebbe un controsenso. Anzi, ragionevolmente, un SaaS ben progettato avrà ben una componente specializzata nella gestione di API e interoperabilità col mondo esterno.
• il gateway API potrebbe esso stesso essere un servizio cloud erogato come SaaS? Se così fosse, pur rimanendo inalterata la logica del gateway, diventa più complicato metterlo in comunicazione con le banche dati dell’erogatore o con i software del fruitore che, a loro volta, sono altri SaaS ospitati su cloud (nel senso di data center) diversi e distanti…
• se non si hanno competenze interne per gestire il gateway, configurarlo, definire le mappature di schemi dati diversi ecc. il rischio potrebbe essere quello di aumentare la complessità del sistema e il numero di soggetti esterni a cui si affida la cura del sistema informativo.
• il fatto che il gateway API faciliti la conversione di schemi di dati, in qualche misura, può essere un freno all’affermarsi di modelli dati standard (caldeggiati anche dal ModI) sia per la gestione dei dati nei database, sia per la modalità con cui questi sono resi disponibile tramite servizi digitali?
• se invece si hanno competenze interne, non solo per gestire il gateway, ma anche per “programmare” sistemi anche semplici che interagiscono con banche dati o altri servizi esposti tramite la PDND, il gateway API è sicuramente un vantaggio, perché si fa carico di tutto lo strato di autenticazione e sicurezza e resta “solo” da preoccuparsi dei contenuti[/ref]Con una visione molto naif, l’aspirazione è quella di avere disponibile a pochi passi un componente informatico che analizza una specifica API in formato standard (OpenAPI, per esempio), chiede due o tre dati per l’autenticazione e mette a disposizione un’interfaccia di interrogazione. Si è detto che magari non sempre l’interfaccia di interrogazione libera è il massimo, ma è già un punto di inizio.[/ref].

Conclusione in attesa del mondo perfetto

In un mondo perfetto, nel quale la gestione e la circolazione dei dati fosse effettivamente centrale e strategica e in cui le risorse e le competenze non avessero problemi di scarsità, potrebbe anche essere che, nel disegno di un sistema informativo ideale, la componente gateway API sia fra le principali^[6]Magari insieme a un’altra, troppo spesso negletta: la componente che centralizza identificazione e autenticazione degli utenti (il single sign-on, insomma), legata all’organigramma. … Continue reading ed irrinunciabili, con l’indicazione che qualsiasi condivisione di dati, che parta da sistemi sotto la diretta responsabilità tecnica dell’organizzazione o che parta da sistemi cloud, sia intermediata dal gateway, così da mantenere davvero il controllo sui dati dell’organizzazione, ovunque essi siano memorizzati.

In attesa del mondo perfetto, coltiviamo i dubbi e cerchiamo di fare scelte anche non perfette ma almeno sostenibili, confidando che anche i vertici delle organizzazioni (pubbliche e private) comprendano come la trasformazione digitale sia un fronte d’azione che non brilla per risposte secche e definitive o strade già percorse e sicure. Le scelte da fare non sempre sono facili, anzi, non lo sono quasi mai, anche perché una scelta fatta oggi condiziona e indirizza possibili sviluppi futuri, in un contesto che è in perenne evoluzione. Anche questa, però, è un’altra storia…

Foto da Pixabay