Come è fatto

Partiamo da una descrizione banale dello stack infrastrutturale necessario alle applicazioni.

L’Hardware – È la parte fisica della tecnologia informatica. Sono i dispositivi che permetto l’esecuzione dei programmi, la connessione tra loro ed il trasferimento dei dati. Ad esempio, il nostro PC, notebook o desktop, spento o acceso è l’hardware.

Il Sistema Operativo – È un software, abbastanza generico, necessario per svolgere le interazioni di base con l’hardware. Di fatto nasconde la complessità dell’hardware agli utilizzatori, siano essi umani o altri software. Nei nostri PC è Windows o MacOS per chi ha un’Apple.

Il Middleware – È una categoria di software strana da definire, perché rende disponibili un insieme di funzionalità specifiche in modo generico ad un utilizzatore. Un’ ottimo esempio sui nostri PC è il software per i fogli di calcolo, sia esso EXCEL o Sheets o Numbers. Provate ad aprirlo senza fare altro, vedrete una tabella vuota senza che accada altro. Il vostro programma vi mette a disposizione tante funzionalità per gestire dei dati all’interno di tabelle, ma se non lo iniziate ad usare, a modellare, a personalizzare non fa nulla! Il vostro middleware per il foglio di calcolo vi rende disponibili un’infinità di funzionalità per manipolare tabelle per tutti gli scopi: scientifico, statistico, economico, ecc. Potremmo definire il middleware come quel software che, una volta avviato, non fa nulla se non ci si mette su altro software.

Le Applicazioni – Sono i software che appoggiandosi direttamente sul Sistema Operativo oppure su Middleware, forniscono delle funzionalità specifiche. Un esempio sono i browser come Edge, Safari, Chrome, Firefox che si appoggiano direttamente sul Sistema Operativo e vi permettono di navigare in Internet. Un’altro può essere un foglio Excel realizato per effettuare il calcolo del Codice Fiscale o uno più complesso che permette di effettuare la gestione di una Prima Nota. entrambi sono software che si appoggiano al middleware di Excel.

Nelle applicazioni Web gran parte di questo

Ma il modello non termina qui. Dobbiamo tenere in  considerazione altri due livelli che sono trasversali ai precedenti.

Il Management – Strumenti software che permettono di governare e controllare tutti i livelli dello stack descritti prima. Questi strumenti sono indispensabili sopratutto quando cresce il numero di sistemi. Per questo, mantenere l’esempio con il nostro PC, è più arduo ma possiamo fare l’analogia con la Gestione delle Attività di Windows.

La Sicurezza – È un livello che ha visto aumentare la sua importanza in modo esponenziale negli ultimi venti anni. Si occupa di proteggere i dati da accessi non previsti (confidenzialità), di mantenerli sempre validi (integrità) e  disponibili (availability).

Sono due livelli importantissimi e vitali, il primo con il crescere della complessità, il secondo sempre.

Dove si trova?

Questo modello, nella realtà dove è? Quali sono i sistemi rappresentabili da questo modello?

Il primo esempio lo abbiamo davanti agli occhi, è il nostro PC Windows o Mac. L’hadware è quello che si accende e il sistema operativo è Windows o MacOS. Di middleware vero e proprio non ne abbiamo, concettualmnte Excel è comodo usarlo come esempio, ma in realtà anche Excel è un’applicazione.

Mentre di applicazioni ne abbiamo pieno il PC: per le email, per sentire la musica, per vedere o ritoccare le foto, per scrivere, ecc.

L’altro posto dove questo modello diventa sostanza, sono i datacenter delle aziende. Al loro interno ci sono spesso migliaia di server che possiamo vedere rappresentati in questo modo.

Ovviamente in questi ambienti gli elementi, nei vari livelli, sono differenti come tecnologie software. Sono tutti orientati a fornire servizi applicativi.

Come Hardware ci sono dispositivi di classe enterprise che, difficilmente, potrebbero essere fatti funzionara a casa, sia per necessità di alimentazione elettrica che di raffreddamento.

Tra i Sistemi Opearativi ritroviamo Windows ma in una configurazione totalmente diversa da quello che siamo abituati ad utilizzare nei nostri PC. Poi ci sono molti tipi di Lunux come Debian, Ubuntu, RedHat, CentOS e anche alcuni dedicati ad hardware specifici come l’AIX di IBM.

I Middleware la fanno da padroni, abbiamo Apache HTTP, Apache Tomcat, Nginx per rendere disponibili pagine web e per far eseguire progammi in grado di interagire con esse, ma anche middleware per realizzare dei database come MySQL, PostgresQL, Oracle. Microsoft SQL Server o IBM DB2 

Per ogni livello si possono effettuare scelte tecnologiche differenti. Ma non va dimenticato che una scelta effettuata su un livello può influenzare o vincolare gli altri livelli. Ad esempio se si decide di utilizzare, per i database, il software MS SQL Server si è costretti ad usare Windows come sistema operativo.

Per superare questi vincoli, nel tempo si sono introdotte nuove tecnologie per disaccoppare un livello dall’altro. Nei primi anni del nuovo secolo si è diffusa la tecnologia della virtualizzazione.

Tramite il software di virtualizzazione viene astratto l’hardware, ossia i Sistemi Operativi vengono installati dentro delle macchine virtuali, che si coportano a tutti gli effetti come l’hardware reale. È compito del virtualizzatore quello di gestire i vari dispositivi ed assegnare loro, ottimizzandole, le risorse come il processore, la memoria, i dischi e le porte di rete.

I due vantaggi immediati che hanno ottenuto i datacenter pieni di server sono stati:

1. Ottimizzazione delle risorse hardware – i server fisici assegnati ad un sostema, ma utilizzati solo al 10% erano una realtà diffusa che sparì nel giro di 3-5 anni.
2. Miglioramento delle attività di gestione – in realtà iin questo campo ci è stato un salto epocale. Se, prima, ad un applicativo serviva un sistema di test, potevano passare anche mesi prima che ci si approvvigionasse dell’hardware necessario, venisse installato e configurato come richiesto dall’applicativo. Con la virtualizzazione un semplice comando permette di clonare un ambiente esistente nel giro di pochi minuti.

In sintesi i virtualizzatori hanno realizzato un “mascheramento” dell’hardware ai livelli superiori. Possiamo aggiungere nuovi server ai virtualizzatori moderni e loro si occuperanno di distribuirne le risorse in modo del tutto trasparente ai sistemi soprastanti.

Tra il 2008 e il 2015 si assiste ad un’altra innovazione, sempre legata al concetto di virtualizzazione: i containers. Nati concettualmente per realizzare un ambiente perfettamente isolato per un’aplicazione, hanno di fatto virtualizzato i Sistemi Operativi.

Il concetto di container è quello di realizzare una unità standardizzata di software che raggruppa il codice dell’applicazione insieme a tutte le sue dipendenze (come librerie, framework, e strumenti di sistema) in un unico pacchetto. Questo permette all’applicazione di essere eseguita in modo affidabile e coerente in qualsiasi ambiente informatico, sia esso un computer personale, un server in un data center, o un’istanza in un ambiente cloud.

Sarà una coincidenza che l’esplosione dei servizi in cloud sia iniziata solo dopo il 2007?

Alcuni sviluppatori pensano che gli argomenti della parte infrastrutturale non siano di loro interesse e non li riguardino. Chi ha questa idea faccia suonare le sirene di allarme e inizi a riflettere! Chi disegna un’applicazione è chiamato, in modo più o meno evidente, a prendere decisioni che influenzeranno la qualità del risultato a prescindere di come l’applicazione viene scritta.

Un modello di architettura del software

Queste sono le decisioni che delineano l’architettura del software di cui un’ottima definizione è questa:

Software architecture is the set of design decisions
which, if made incorrectly, may cause your project to
be cancelled.

Eoin Woods

Rende bene il concetto di quanto è importante definire un’architettura adeguata che non ci porti a rischiare di rifare tutto dall’inizio. Dunque le due domande cardine sono: Cosa deve includere un’architettura? A che scopo? Lo scopo principale è quello di stabilire e descrivere, complessivamente, la struttura del software. Ma cosa si debba descrivere e con che livello di dettaglio è anche questa una scelta da prendere. C’è a disposizione un’enorme bibliografia che ci guida in questa scelta.

Per quello che è funzionale alla nostra valutazione del low-code semplifichiamo l’architettura, in modo poco accademico e del tutto generico, in un modello che descrive le aree principali in cui suddividiamo un’applicazione.

Presentation logic – È la parte dove si costruisce l’intefaccia con l’utente-umano. Vengono perfezionati i meccanismi per interagire con l’applicazione. È importante perchè avere delle capacità elaborative che sono complicatissime da usare è il presupposto per il fallimento del software.

Business Logic – Racchiude tutti i meccanismi che permettono di realizzare le funzionalità richieste. In questo livello ci sono i calcoli, le verifiche, i controlli e le validazioni dei dati immessi. Ma anche il tipo e l’organizzazione delle operazioni possibili. Ossia i workflow con cui si opera e la definizione dei ruoli dei vari utenti che effettuano le operazioni. È la logica pilotata principalmente dall’area a cui si rivolge il software progettato. Quindi, ad esempio, un’applicazione per fare la dichiarazione dei redditi avrà un insieme di operazioni e controllo totalmente diversi da quella per gestire un magazzino o uno studio medico.

Data Logic – È la logica con cui sono memorizzati i dati, sia in modo persistente all’interno di database, sia in modo temporaneo per essere utilizzati nelle differenti operazioni. In quest’area si definiscono i dati necessari alle operazioni e come questi vengono rappresentati.

Come si colloca nell’infrastruttura?

Quello che potrebbe sembrare un passaggio semplice, ossia posizionare le aree del nostro modello di architettura all’interno dell’infrastruttura, è un’altra scelta architetturale. Vediamolo per ciascun aspetto logico del nostro modello.

Dove realizzare la Presentation Logic è una scelta che vincola o è vincolata dall’infrastruttura. Infatti se si vogliono utilizzare pagine dinamiche con il linguaggio PHP, dovremo avere un Middleware che lo permetta. Se invece scegliamo di realizzare questa parte in modo che risieda tutta nel browser degli utenti. potremmo svilupparla tutta in Javascript.

Per la Business Logic ci sono più possibilità di colllocazione. Possiamo codificarla nel browser, usando di nuovo Javascript; nel Middleware che realizza il dialogo web, usando PHP, Java o altri linguaggi, oppure all’interno dei Middleware dei database con script o procedure SQL. Anche direttamente nel Sistema Operativo, con script e attività schedulate (personalmente è una scelta che trovo datata e da evitare il più possibile). Difficilmente la Business Logic viene realizzata tutta in un unoci layer infrastrutturale, ma si sfruttano i vantaggi di ciascuno per ottenere il risultato migliore.

L’aspetto dei dati ad uno sguardo frettoloso sembra semplice: abbiamo i database, quindi a seconda del Middleware usato per la nostra struttura di database (non a caso si chiamano DBMS, DataBase Management System) descriviamo i nostri dati in tabelle e relazioni e tutto finisce lì. Nulla di più lontano dalla realtà. I dati usati nella applicazioni hanno una loro vita e vengono usati in differenti operazioni, quindi il dove sono collocati, è nuovamente una scelta non così scontata.

Quindi la Data Logic sicuramentè sarà collocata in gran parte nel middleware dei database, per i dati che hanno bisogno di una persistenza tra le differenti operazioni, sessioni ed utenti. Però molti spesso collocano alcuni dati persistenti direttamente nel Sistema Operativo. Due esempi molto conosciuti sono il Document Managemen System Alfresco (ora di Hyland) che memorizza tutti i documenti all’interno di un albero di sottocartelle praticamente impossibile da navigare. Oppure il più noto Content Management System WordPress per la creazione di siti web, che organizza molti dei suoi contenuti in sottocartelle talmente facili da navigare che devono essere protette adeguatamente da accessi indesiderati.

Alcune strutture dati, di solito quelle che hanno vita all’interno delle interazioni utenti, possono essere realizzate nei browser di chi accede all’applicazione.

Cosa è l’architettura del software, è lo stesso dell’architettura applicativa?

È strano mettere all’ultimo questo titolo, ma strumentalmente abbiamo costruito un modello di architettura software senza darne una definizione. Piuttosto abbiamo delineato dei livelli, abbastanza comuni e di immediata comprensione, per capire come si legano con l’infrastruttura. Ma è questa l’architettura del software? Possiamo vedere questa come la descrizione:

• di alto livello della struttura di un sistema software. Questo include le decisioni riguardo alla suddivisione del sistema in componenti e la definizione delle responsabilità, delle funzionalità e delle interazioni di ciascun componente.
• dell’organizzazione e la disposizione delle parti del software, come i moduli, i componenti, le interfacce e i dati, per soddisfare i requisiti specifici del progetto.
• delle scelte che si traducono in linee guida e vincoli per la codifica del software.

Però non si parla di pattern, di quali librerie, quali framework usare, di come organizzare il nostro software in componenti (o moduli, o classi, o funzioni, o quello che preferite…), di come il nostro software deve integrarsi con altri. Insomma sembra che manchino tante cose.

Non manchano all’architettura Software, ma appartengono ad un’altra architettura, più specifica, che si chiama Architettura Applicativa. possiamo vedere quest’ultima come una serie di scelte che indirizzano aspetti più di dettaglio che variano a seconda delle esigenze specifiche dell’applicazione. Ad esempio:

1. Struttura e Componentizzazione:
   • Definizione dei componenti dell’applicazione, come moduli, servizi, librerie, ecc.
   • Suddivisione dell’applicazione tra i livelli logici (es. presentazione, logica di business, accesso ai dati).
2. Comunicazione e Integrazione:
   • Modelli di comunicazione interna ed esterna (es. API REST, SOAP, gRPC).
   • Integrazione con sistemi esterni, come database, servizi web, sistemi ERP.
3. Gestione dei Dati:
   • Schema del database e strategie di accesso ai dati (ORM, SQL diretto, NoSQL, GraphQL).
   • Politiche di gestione delle transazioni e integrità dei dati.
4. Interfaccia Utente:
   • Design dell’interfaccia utente e dell’esperienza utente (UI/UX).
   • Framework e tecnologie per la realizzazione dell’interfaccia (React, Angular, Vue.js).
5. Sicurezza:
   • Autenticazione, autorizzazione e controllo degli accessi.
   • Protezione dei dati e conformità alle normative sulla privacy (GDPR, HIPAA).
6. Prestazioni e Scalabilità:
   • Ottimizzazione delle prestazioni e gestione del carico.
   • Scalabilità orizzontale e verticale, bilanciamento del carico.
7. Affidabilità e Disponibilità:
   • Strategie per la gestione degli errori e la resilienza dell’applicazione.
   • Backup, disaster recovery e alta disponibilità.
8. Manutenibilità e Evolvibilità:
   • Pratiche di sviluppo per facilitare la manutenzione e l’evoluzione del software (es. programmazione modulare, uso di pattern di design).
   • Documentazione e standardizzazione del codice.
9. Deploy e Gestione dell’Ambiente:
   • Strategie per il deploy (continuous integration/continuous deployment).
   • Gestione dell’infrastruttura e dell’ambiente di esecuzione (cloud, on-premise).
10. Conformità e Standard:
    • Adesione a standard e protocolli del settore.
    • Conformità con le normative e le best practices dell’industria.

Si capisce che c’è una differenza, nei contenuti e nelle finalità, tra l’architettura del software e quella applicativa. Ma questa differenza è un’area grigia, che non è nettamente ed univocamente delineata né dal mondo accademico, né dal mondo dei produttori di software. La stessa gerarchia tra i due termini spesso è considerata al contrario, per cui non è detto che, la parte di descrizione del software sia sempre, o per forza, una vista più generale della descrizione dell’applicazione. È una questione di terminologia, chi usa software come termine più generico rispetto al termine applicazione, e chi li usa al contrario. La tanto osannata Wikipedia riporta, senza fonte, questa definizione:

Applications architecture defines how multiple applications are poised to work together. It is different from software architecture, which deals with technical designs of how a system is built.

WikiPedia

Trovo logico, cosiderare i due termini con queste accezioni:

Software: Il termine “software” è un termine generico che si riferisce a qualsiasi programma o insieme di istruzioni eseguite su un computer. Include tutto ciò che è non fisico e che è necessario per eseguire una funzione su un computer, come sistemi operativi, programmi di utility, programmi di elaborazione testi, giochi, e codici di database.

Applicazione (App): Un’applicazione, spesso chiamata “app”, è un tipo di software progettato per aiutare l’utente a svolgere attività specifiche. Le applicazioni sono più specifiche nei loro usi rispetto al software in generale e sono tipicamente progettate con un’interfaccia utente che facilita queste attività, come la modifica di documenti, la navigazione su internet, o la gestione di email.

Qui tralasciamo di approfondire l’architettura applicativa, poichè non vogliamo fare un testo accademico sulle architetture. Ci serve solo avere un’idea complessiva, per essere in grado di effettuare delle valutazioni, ponderate, del mondo del low-code.

Altri aspetti (che trascuriamo) dello sviluppo applicativo

Metodologia di sviluppo

Modelli ed architetture a parte, nello sviluppo applicativo c’è un’altro aspetto fondamentale che non va trascurato: la metodologia di sviluppo. La considero l’architettura degli aspetti umani dello sviluppo applicativo.

Senza entrare in temi di psicologia o di intelligenza emotiva, ci sono elementi prettamente umani che vanno governati e coordinati per assicurare l’avanzament delle attività di sviluppo. Come si comunica all’interno del team; come si comunica all’esterno; come, se e quando si condividono i problemi che emergono nello sviluppo applicativo; come si risolvono i contrasti, ecc.

Leggo il tentativo di affrontare tali aspetti nelle metodologie di sviluppo che possono essere esplicite e dichiarate (“noi seguiamo la metodologia agile”) o implicite con una serie di regole e procedure usate “per tradizione”. Ma possono essera antiche (“ci atteniamo al cronoprogramma o al gantt”) o moderne.

Metodologia di test e passaggio in produzione

Una volta sviluppata la nostra applicazione, come si prova? come si rende disponibile? Non sono aspetti così evidenti per un one-man-developers, ma per team di sviluppo articolati e per applicazioni complesse sono molto sensibili. E per me un team di sviluppo articolato è un team di più di tre persone.

In sintesi sotto il nome di Metodologia di Test ci sono le prcedure che difiniscono chi, come, dove e perché deve effettuare i test:

• perché – sembra ingenuo ma è la prima cosa che, anche in modo non esplicito, viene stabilita. Di solito decidiamo di eseguire i test “per sapere che tutto vada bene”. Ma gli obiettivi potrebbero essere: per vedere che non ci sono errori nell’esecuzione del codice; per verificare che i requisiti siano soddisfatti; per valutare le prestazioni; per valutare quanti utenti possiamo avere.
  Il perché può anche essere negativo. NON eseguiamo i test: perché costa troppo; perche non abbiamo dati con cui realizzarli; perché non è disponibile un ambiente di test; ecc.
• chi – banalmente identifica chi esegue i test per dire che si può rendere disponibile (passare in produzione) l’applicazione.
• come – definire come testare un’app e quali test effettuare è forse la parte più delicata, perché più questo aspetto è definito formalmente e più si è giustificati a non approfondire o allargare i test.
• dove – servono differenti ambienti per testare differenti aspetti? Ricordo un cliente che aveva questi ambienti oltre all’ambiente di sviluppo: test funzionale, test di integrazione, test di regressione, test di qualità, test utenti e formazione. Si un ambiemte dedicato a fare la formazione agli utenti, quindi per ogni linea applicativa esistevano un ambiente di produzione, uno di sviluppo, cinque di test ed uno di formazione.

La complessità dei differenti ambienti rende necessaria, non tanto per lo sviluppo iniziale, quanto per lo sviluppo di modifiche, una Metodologia di passaggio in produzione. Immaginiamo di dover fare una modifica all’applicazione dell’esempio precedente: la modifica si deve applicare su sei ambienti prima di essere applicata in produzione. Non si possono modificare gli ambienti con modalità improvvisate e non tracciate.

Le metodologie di sviluppo, di test e di passaggio in prodizione sono altri temi che non approfondiamo qui, ma vogliamo solamente collocare correttamente perché, si vuole capire se sono  influenzate, o meno, dal mondo del low-code.