Nell’articolo precedente abbiamo visto quanto il mondo presente sia VUCAniano e quanto sia necessario curare le catene di dipendenza tra organizzazioni, aziende e pubblica amministrazione per garantire che le cose funzionino.
In questo nuovo articolo, riprendendo il tema già affrontato sull’importanza della ICT come pilastro di tutta la nostra società, esamineremo invece alcune caratteristiche specifiche della tecnologia e delle motivazioni alla base della loro esistenza.
Il senso di questo mio intervento vuole infatti essere in primo luogo una panoramica sul quando e come si è creato l’attuale sistema infrastrutturale informatico (che possiamo definire iper-complesso) per fare poi alcuni ragionamenti su quali sono i livelli a cui è possibile intervenire oggi per semplificarne i flussi e far sì che la digitalizzazione sia sempre più a misura d’Uomo.
Questo, assieme ad alcuni approfondimenti di tipo tecnico che ho indicato alla fine dell’articolo per chi volesse addentrarsi in maniera più completa su alcuni contenuti specifici.
Partiamo ora dall’inizio.
In principio fu… l’anarchia
La nascita dell’informatica è, per convenzione, fissata all’anno 1946, anche se i primi calcolatori elettronici programmabili furono già realizzati alla fine degli anni 30.
Fino alla fine degli anni 60 la tecnologia informatica fu completamente proprietaria, ossia ogni produttore aveva i propri standard per l’hardware interno al computer, per i cavi di connessione fra terminali e computer e, sino alla fine degli anni 50, anche per i linguaggi di programmazione, fortemente legati all’hardware stesso.
Non esistevano regole né standard pubblici: ogni produttore programmava come voleva l’evoluzione della propria tecnologia. La diffusione degli strumenti era per produttore, i clienti sceglievano IBM, Digital, HP etc. ed erano costretti a seguire il produttore praticamente in tutti i componenti informatici.
Le cose, poi, iniziarono ad evolvere,prima con la nascita dei linguaggi di alto livello multipiattaforma dal lato software; poi, qualche anno dopo, con la creazione dello standard dei PC aperto a diversi costruttori e, infine, con l’avvento di Internet con e il suo standard di comunicazione digitale fra diversi dispositivi.
Tutto ciò, una volta messo a sistema, ha consentito nel corso dei decenni di creare l’enorme, complessa, onnipresente infrastruttura digitale che oggi consideriamo quasi “naturale”, dove i dispositivi di interfaccia utente come PC, tablet e smartphone possono interagire fra loro e con le informazioni e i servizi posti in grandi centri di elaborazione dei dati (data center) raggiungibili attraverso Internet.
Questa, in sintesi, è la situazione che, come utenti, noi vediamo oggi da “fuori”.
E già questa successione di punti è considerata per molti utenti complicata “perché ci sono tantissime app e programmi, con tante funzioni…” mentre vorrebbero piuttosto concentrarsi sui singoli obiettivi per cui lo strumento è necessario, come ad esempio scrivere una lettera, prenotare una visita medica, acquistare un prodotto…
Ma tutto questo è in sé, strutturalmente, inattingibile. Cerchiamo allora di capire meglio perché. Cosa c’è, ad esempio,“dietro” l’interfaccia utente? E come è davvero organizzata la tecnologia oggi?
I livelli sono tanti, in relazione tra loro e spesso agiscono attraverso relazioni funzionali stratificate. Tra questi “passaggi” un ruolo importante lo giocano i “sistemi client-server”.
Facciamo quindi un altro passo indietro. O meglio, “dentro”.
I sistemi client-server
L’architettura tecnologica client-server risale alla fine degli anni ’80 .
Secondo tale architettura, base dell’informatica distribuita, un programma client, operante su un dispositivo client, può usufruire, attraverso una rete di comunicazione, di funzionalità messe a disposizione da altri programmi (server) operanti su computer server più potenti e condivise fra numeri anche elevati di client, come schematizzato in figura:
Lo stesso servizio Web, ad esempio, nato nel 1989 e diffuso al pubblico nel 1991, segue questa architettura.
Anche oggi la maggior parte delle nostre interazioni con gli strumenti digitali ha luogo tramite applicativi client. Su smartphone e tablet tipicamente sono app, mentre su PC, smart TV ed altri dispositivi tipicamente sono il browser o programmi client specifici. Essi stessi poi richiedono informazioni e funzionalità a programmi server “in qualche punto della rete”.
A loro volta i programmi server, accessibili tramite la rete aziendale se ci troviamo all’interno di un’azienda oppure accessibili via Internet, operano su computer specifici che si trovano o dentro centri di elaborazione dei dati proprietari di aziende o dentro i grandi data center che formano a loro volta il cloud.
Possiamo quindi affermare che le varie funzioni atte a gestire i dati necessari per una determinata operazione vengono spesso attinti “da sistemi globali che gli utenti non devono preoccuparsi di comprendere” (William Gibson in ).
Un esempio di come questo accada, relativo ad una interazione per la prenotazione di un viaggio, è riportato in figura:
Da qui discende che, al di là dell’interfaccia o del dispositivo che stiamo usando per richiedere le nostre operazioni, esiste un vero e proprio universo fatto di programmi, più o meno complessi, che dialogano fra loro per completare tali operazioni a prima vista semplici e magari anche rapide.
Questo insieme di strumenti tecnologici, dal cui buon funzionamento dipendono ormai tante parti della nostra vita, è diventato, nel tempo, sempre più complesso, anche al di là delle intenzioni dei diversi sviluppatori che hanno concorso alla loro realizzazione.
L’insostenibile complicazione del Digitale
Aprendo ulteriormente lo sguardo sul mondo tecnologico che sta oltre l’interfaccia utente, una delle prime cose che possiamo notare è il numero enorme di linguaggi di programmazione attraverso i quali sono stati e vengono realizzati da parte dei programmatori i programmi applicativi (app, pagine web, componenti server, software di base, ecc…
(NB: a un approfondimento sulla varietà dei linguaggi è dedicato un box specifico al termine dell’articolo).
Proseguendo ora nel nostro storytelling, vediamo che – accanto alla complessità intrinseca nei linguaggi di programmazione e alla loro rapida obsolescenza – c’è stata un’ulteriore evoluzione verso la complicazione delle architetture software stesse per via della estremizzazione delle architetture a strati.
L’architettura a strati, infatti, prevede di affidare compiti diversi a sezioni diverse del software. E, in linea di principio, è un approccio ottimo alla realizzazione del software… ma quando gli strati si moltiplicano sempre più e diventano ulteriormente strutturati al loro interno la cosa può sfuggire di mano.
Un applicativo server che fornisce servizi a tantissimi clienti da PC, tablet e smartphone, oggi, deve dunque essere necessariamente robusto, ossia capace di gestire errori di funzionamento e resistere, per quanto possibile, ad attacchi informatici, assieme al fatto di essere scalabile, ovvia capace di continuare ad erogare i propri servizi anche al crescere del numero di richieste.
Uno dei modi molto usati per ottenere questo è “incapsulare” l’insieme di componenti software scritti dal programmatore, di librerie di sistema e di altre parti software necessarie per il funzionamento entro un “contenitore software”, chiamato appunto container.
I container, infatti, consentono di moltiplicare le componenti server in caso di aumento del carico, ma vanno gestiti adeguatamente utilizzando strumenti software appositi e configurazioni specifiche per ogni fornitore di infrastrutture cloud, come per esempio Amazon AWS, Google o Microsoft…
Affinché tutto “fili liscio” in tale successivo o contestuale flusso di attività, è quindi necessario essere in grado di:
- scrivere codice di qualità per realizzare i componenti software server o client nel minor tempo possibile;
- costruire opportunamente i container o i server virtuali dove questi componenti devono operare;
- configurare tali elementi in modo robusto, scalabile e sicuro.
È già chiaro in sé che niente di tutto questo può essere semplice.
La possibilità di errore è dietro l’angolo: durante la presentazione del rapporto cybersecurity Italia 2020 di Osservatori.NET, lo scorso febbraio, è stata presentata la stima che i 2/3 dei futuri incidenti di sicurezza nel cloud avverranno per debolezze legate ad errori di configurazione!!!
E stiamo parlando delle componenti software dei sistemi IT cui sono affidati componenti fondamentali della nostra vita.
Di fronte a tali difficoltà la domanda, come si dice, sorge spontanea: ma perché l’evoluzione tecnica del Digitale si è manifestata in questo modo e secondo tali coordinate di complessità?
I diversi perché dell’evoluzione tecnologica
Sono tante le motivazioni per cui si è giunti alla situazione corrente. Le principali, le ricordo, sono:
- L’attività di scrittura di software destinato agli utenti finali, sia interni alle aziende (B2B) che appartenenti al grande pubblico (B2C) è un vero e proprio business con numeri potenzialmente molto grandi.
- In particolare, scrivere software destinato ad un’utenza di massa su Internet può avere ritorni con numeri enormi: se consideriamo, ad esempio, un’app di cui lo sviluppo costa 50.000 euro e che viene venduta a 3 euro la copia in un milione di esemplari, ecco che, detratte le quote per Apple e Google, frutta comunque più di un milione di euro al venditore…
- Per soddisfare questa massa di potenziali utenti il software deve essere scritto il più in fretta possibile.
- La richiesta di software per utenti finali si è tradotta nella richiesta di ambienti di sviluppo e linguaggi di programmazione con sempre nuove funzionalità, ossia di sistemi software per sviluppare altro software.
- I linguaggi di programmazione sono stati realizzati da gruppi ristretti di programmatori iper-esperti, che nella loro creazione hanno di solito tenuto conto delle necessità di chi doveva usarli per scrivere altro software; quando poi sono state affiancate librerie, magari a pagamento, si è innestata una logica commerciale tesa ad attirare un numero sempre maggiore di programmatori (clienti) sulla propria piattaforma, o per profitto diretto, o per profitto indiretto (corsi di formazione, consulenze…).
- Il software infrastrutturale (container, server web, DBMS…) viene di solito venduto a licenza; quasi sempre la formazione specifica su tale software, erogata dai vendor o da loro partner, è molto costosa (i profitti di tale formazione fanno parte del guadagno del vendor): rilasciare nuove versioni con tante nuove funzionalità significa anche erogare nuovi corsi e avere nuovi guadagni.
- Analogamente, una nuova versione significa anche nuove consulenze verso i clienti finali per assisterli durante la migrazione dei propri sistemi con l’inserimento; alle volte, vedendo certi software molto complessi, viene addirittura l’idea che la complessità sia volutamente inserita per “vincolare” tutta la catena dagli amministratori di sistemi e dagli sviluppatori sino al cliente finale all’uso del componente software entro la propria architettura.
- La vendita di Software come servizio sul cloud (SaaS) è orientata allo stesso scopo, attrarre il cliente (in modo tale che paghi un canone annuale) e rendergli complicato passare ad un altro fornitore, non soltanto per il trasferimento dei dati, ma anche per il trasferimento di una infrastruttura tecnologica che genererebbe un costo alto senza portare veramente un valore aggiunto: in pratica è come pagare moltissimo un trasloco, in cui dobbiamo trasportare anche una parte degli impianti elettrici ed idrici ed adattarli alla nuova casa in cui andremo ad abitare.
Quindi il problema è spesso legato alla prevalenza di interessi commerciali, con i conseguenti rischi di errori e di fragilità entro sistemi, indispensabili per la nostra vita.
Come porre rimedio? Come ottenere una ICT, ormai pilastro della società, più a misura umana?
Per una ICT a misura umana
In primo luogo occorre che gli stati e le istituzioni internazionali impongano standard di qualità, non solo in settori molto specifici come il software per le apparecchiature elettro-medicali, ma per la produzione di tutti quei software usati entro le infrastrutture o comunque su servizi critici come la produzione di energia.
La creazione di Leggi come la direttiva europea NIS va sicuramente in questa direzione.
Ma occorre andare oltre, occorre cioè superare le mere logiche commerciali: i legislatori devono essere consapevoli della importanza di questi sistemi che permeano la nostra vita e la cui evoluzione deve essere maggiormente controllata a favore della collettività, almeno nei nostri sistemi democratici.
Possiamo dire quindi che è necessario “umanizzare la tecnologia”, sia nei confronti degli utilizzatori finali, fornendo nei servizi essenziali delle interfacce utente “umanamente usabili”, sia per gli addetti ai lavori, permettendo lo stabilizzarsi di conoscenze nel tempo e riducendo certe barriere di ingresso.
È importante inoltre tenere conto che molte persone, più o meno giovani, stanno perdendo il proprio lavoro per via delle rapidissime e dirompenti trasformazioni socio-economiche che stiamo vivendo in questo periodo e che nei prossimi anni saranno ancora maggiori. Molti di questi non potranno reinserirsi nello stesso settore.
Questo, mentre assistiamo nel contempo alla mancanza di persone qualificate soprattutto nel settore ICT: mancano programmatori, mancano amministratori di sistema, mancano specialisti di prodotto… questo penalizza soprattutto le piccole imprese del settore ICT o le aziende che hanno sede in provincia fuori dalle grandi città.
È necessario dunque riqualificare persone formando professionalità richieste dal settore ICT: se gli strumenti di sviluppo sono meno complicati, ecco che questo passaggio diventa più facile.
(Accanto a questi temi, comuni in tutto il mondo, si aggiunge un problema purtroppo caratteristico dell’Italia: il cosiddetto body rental, di cui parlo in specifico in uno degli approfondimenti a fine articolo).
Simplicity e Security By Design
Arrivati a questo punto, dopo un’ampia panoramica sulle problematiche e sui possibili punti di risoluzione, riassumiamo per concludere quali sono quindi le azioni necessarie per “umanizzare” la tecnologia.
Innanzitutto partirei dai temi della semplicità, della robustezza e della sicurezza di dati e dei sistemi: questi vanno necessariamente introdotti come requisiti cogenti per i progetti di sviluppo informatico, come del resto chiedono leggi come il GDPR, normative come la ISO/IEC 25010, insiemi di buone pratiche come ITIL e COBIT.
A tal fine è necessario quindi:
- Introdurre semplificazioni nell’uso della tecnologia, e quindi realizzare interfacce utente il più possibile semplici ed ergonomiche, pensate per chi le deve usare, soprattutto nel lavoro quotidiano.
- Semplificare, per quanto possibile, la produzione della parte della tecnologia destinata a fornire le funzionalità per gli utenti finali, quindi utilizzare linguaggi senza complessità inutili e provvedere all’organizzazione di ambienti di sviluppo ergonomici per il buon lavoro degli sviluppatori.
- Semplificare e rendere robuste, per quanto possibile, le componenti infrastrutturali della tecnologia in modo da ridurre la possibilità di errori di configurazione e fragilità.
Come abbiamo visto, ognuno di questi passaggi richiede capacità non solo di “visione” e “strategia”, ma anche una buona dose di “operatività” su più livelli.
Ed è chiaro, a questo punto, che oltre alla semplificazione della tecnologia, occorre introdurre da un lato una specifica ed adeguata formazione alla tecnologia per gli addetti ai lavori in primis, e in secondo luogo creare un uso consapevole della tecnologia in una platea di utenti e consumatori più ampia di quanto non sia oggi.
Questo, in specifico, sarà il tema del prossimo articolo. Alla prossima, dunque, non prima di indicarvi di seguito alcuni “spazi”di approfondimento tematici e alcune mie riflessioni personali e professionali.
Giulio Destri
ALGORITMI E STRUTTURE SOFTWARE: CHE PASSIONE!
La passione che alcuni sviluppatori hanno per certi costrutti, algoritmi, strutture software, non è sempre dovuta a meri motivi economici o alla difesa delle proprie competenze pregresse, ma anzi è una giusta passione per il proprio lavoro.
Tuttavia essa non deve mai fare scordare cosa sono i codici sorgenti che originano il software: sono istruzioni che noi diamo ai computer su come svolgere le funzioni che gli utenti fruiranno attraverso le interfacce utente o che saranno eseguite in modo completamente autonomo.
Sono procedure su come fare le cose per poter essere utili agli utenti: chi scrive il codice sorgente deve pensare anche agli utenti.
Bisogna evitare di cadere nel dettaglio e perdere di vista la visione di insieme. La tecnologia serve da supporto, da fattore abilitante per il business e per la vita: è un mezzo e non il fine, tranne che per chi la produce e la vende.
La tecnologia sta diventando sempre più indispensabile per gli esseri umani, quindi occorre pensare tutti i processi di produzione ed erogazione della tecnologia in modo umano. La nascita di approcci nuovi come il DevOps va in questa direzione.
PARLIAMO DI BODY RENTAL
L’espressione, il cui significato letterale è “noleggio dei corpi” indica, in ambito informatico, la fornitura di figure professionali come sviluppatori Java, amministratori di sistema ecc… da parte di aziende piccole e grandi a clienti finali, che in questo modo evitano di assumerle.
Nella sua forma peggiore assume la forma di un vero e proprio “caporalato” elettronico in cui lavoratori a partita iva sono pagati circa un centinaio di euro al giorno, “rivenduti” dalla prima azienda ad un’altra con un piccolo margine (ad esempio 150 euro al giorno) e, dopo due o tre livelli ognuno dei quali aggiunge un margine, si trovano a lavorare in una grande azienda insieme ad altre decine di persone, che si trovano nella stessa situazione.
Dopo due o tre anni, finita la necessità della loro opera per il cliente finale, vengono spostati in altri posti o addirittura lasciati a casa. In questo modo, se l’azienda cliente finale paga 300 euro al giorno per la persona, 2/3 del compenso vanno agli intermediari…
Le persone in questa situazione non hanno ferie, non hanno malattia, assicurazioni etc., e sono spesso costrette a cercare da sole le informazioni tecniche che servono per il proprio lavoro.
La necessità del lavoro remoto ha portato alla evoluzione: il remote body rental, in cui una persona da casa svolge il lavoro senza nemmeno parlare con i propri colleghi (e magari senza nemmeno conoscerli) con il coordinatore che gli passa le singole attività da svolgere come unico contatto… e in questo modo non può nemmeno confrontarsi con altri ed è costretta ad accettare le condizioni pur di poter lavorare.
Le persone in queste condizioni sono poco motivate, producono codici sorgenti di scarsa qualità e quindi sistemi fragili. I recenti casi di fallimenti clamorosi di sistemi informatici della pubblica amministrazione italiana sono, almeno in parte, riconducibili a questo fenomeno presente nelle forniture
PER FINIRE, TORNIAMO ALL’INIZIO, OVVERO AL “LINGUAGGIO”
Alcuni linguaggi sono storici, come il COBOL, nato nel 1959 e la cui versione in uso oggi risale agli anni 90. Esistono programmi COBOL scritti nei primi anni 80 e tutt’ora in uso, specialmente nei sistemi informatici bancari, il che dimostra che questo linguaggio da allora è cambiato molto poco.
Altri linguaggi, come Java, C# e PHP, sono nati tra gli anni 90 ed il 2000 e sono molto diffusi per applicazioni web, portali web, applicazioni gestionali.
Accanto ad un nucleo base, ossia la parte originaria del linguaggio, con le istruzioni basilari per compiti semplici, questi linguaggi si sono arricchiti nel tempo di librerie sempre più ampie e ricche di funzionalità, che hanno reso possibile realizzare un’applicazione in tanti modi diversi.
Le nuove scelte di implementazione disponibili però spesso hanno aumentato enormemente la complessità dei programmi e reso sempre più stringente la necessità di governare adeguatamente sia lo sviluppo sia la evoluzione e mantenimento delle applicazioni.
Pertanto, se per un programmatore COBOL, una volta appreso il linguaggio, praticamente serve pochissimo aggiornamento, per un programmatore C# o Java serve un aggiornamento ogni 3-4 anni al massimo, se vuole stare dietro alla evoluzione del linguaggio stesso.
Altri linguaggi ancora, specialmente alcuni di quelli dedicati alla interfaccia utente, come ad esempio Angular o React, hanno addirittura dei cicli di vita molto brevi. La prima versione di Angular (AngularJS) è stata rilasciata da Google nel 2010.
Poi, a partire dal 2016, è stata progressivamente sostituita dalla nuova, incompatibile con la precedente.
In sostanza quindi abbiamo linguaggi piuttosto complessi da apprendere, che, dopo alcuni anni, vengono abbandonati in favore di nuove versioni o addirittura nuovi linguaggi, costringendo i programmatori ad apprendere tali nuovi linguaggi quasi da zero…
Bibliografia e Approfondimenti
Robert Orfali, Dan Harkley, Jeri Edwards – Client-Server survival guide – Ed. John Wiley & Sons, 1999
William Gibson – Aidoru – Mondadori, 1996
CREDITS IMMAGINI Immagine di copertina (rielaborata): ID Immagine: 54456198. Diritto d'autore: studiom1 ID Immagine: 111182205. Diritto d'autore: Preechar Bowonkitwanchai Icone nei box ID Immagine: 127615654. Diritto d'autore: vectorhome ID Immagine: 32849727. Diritto d'autore: yskiii ID Immagine: 26426662. Diritto d'autore: gdainti
