Il potere del low-code è reale o superato? Come possiamo valutarlo?

Una situazione impossibile

Immaginatevi questa situazione, in un’azienda tecnologica, c’è un team che si trova davanti a un bel guaio: devono creare un’applicazione per gestire i rapporti con i clienti e hanno solo poche settimane per farlo. Sembra quasi una missione impossibile, vero? Eppure, eccoli qui, tre settimane dopo, non solo hanno finito in anticipo, ma hanno anche messo su un sistema CRM che funziona alla grande e su misura per le loro esigenze. Niente notti in bianco a scrivere codice o trucchi da maghi dell’informatica, ma solo la magia delle piattaforme low-code.

Questi strumenti stanno cambiando completamente il gioco, rendendo lo sviluppo software un processo veloce, efficiente e alla portata di tutti. Impressionante, no? Ma è proprio vero?

Si legge nel web che le piattaforme low-code sono strumenti di sviluppo software che permettono di creare applicazioni scrivendo poco codice tradizionale o addirittura senza scriverlo. Usando un ambiente visuale, dove gli utenti possono utilizzare interfacce drag-and-drop e modelli pre-costruiti, permettono di assemblare e configurare le funzionalità di un’app. Il focus è sulla semplificazione del processo di sviluppo, rendendolo accessibile anche a chi non ha competenze avanzate in programmazione.

Si presentano particolarmente utili per lo sviluppo rapido di applicazioni aziendali, l’automazione dei processi e la creazione di soluzioni personalizzate per rispondere a esigenze specifiche del business. Grazie a queste piattaforme, aziende di ogni dimensione possono innovare a costi accettabili ed adattarsi rapidamente in un mercato in continua evoluzione.

Allora avanti tutta con il low-code! O no?

Cosa si intende per piattaforma low-code?

Sebbene, a pelle, esista un concetto comune di low-code, non esiste una definizione univoca. Potete leggere le posizioni di alcuni brand altisonanti cliccando i loro nomi:

KPMG

KPMG investe molto nel low-code tanto da aver creato neòl 2021 il Low-Code Center of Excellence. Ma non sono riuscito a trovare una sua definizione di Low-code. O meglio, risponde alla domanda Cosa è il low-code con parole non sue, ma dell’azienda ServiceNow:
Low-code is a refined way for companies to develop high-end applications which, according to ServiceNow, can perform up to 10 times faster compared to those developed traditionally.

Sinceramente non calza con molte piattaforme low-code che conosco.

In un’altra pagina parla del low-code come “one of the more disruptive technologies to hit the enterprise since the cloud. It enables you to create powerful software applications using a simple graphical interface instead of arcane programming skills.

Gartner

Con un approccio più strutturato Gartner fornisce una sua definizione sia nel suo sito Peer InsightsGartner defines low-code application platforms (LCAPs) as application platforms that are used to rapidly develop and run custom applications by abstracting and minimizing the use of programming languages.” 

Poi condivide le sue considerazioni sulla crescita del mercato del low-code, Infine rende disponibile uno dei suoi famosi Magic Quadrant, dove “Gartner defines LCAP solutions as application platforms used to rapidly develop custom applications.“. Ossia sparisce il riferimento al run.

IBM e Kindryl

Per IBM “Low-code is a visual approach to software development that enables faster delivery of applications through minimal hand-coding“. Nella stessa pagina, viene fatta una considerazione interessante sulle differenze tra low-code e no-code: “However, no-code products are specifically targeted for business users, allowing them to create custom apps without expert development skills and knowledge

Mentre Kindryl, la parte dei servizi IBM che è stata raccolta in un’azienda ad-hoc, non spende energie sulla parte concettuale ma opera direttamente annunciando che Microsoft recently awarded Kyndryl with the Low Code Application Development Specialization.

Queste definizioni mostrano come ciascuno plasma la definizione di low-code evidenziando criteri differenti. Chi evidenzia la rapidità del processo di sviluppo, chi considera anche gli aspetti dell’ambiente di produzione, chi considera le competenze necessarie e chi si rivolge solo agli sviluppatori. Tutti però mettono alla base di tutto gli aspetti visuali e di drag-ann-drop

Secondo me, le definizioni precedenti peccano perché fanno tutte riferimento ad un generico sviluppo applicativo che viene velocizzato, senza considerare i suoi molteplici aspetti. Quindi facendo credere che il low-code ha una sua capacità magica di far andare meglio qualsiasi sviluppo applicativo.

Penso che questo sia il motivo principale per cui il low-code è visto con diffidenza da chi ha esperienze di sviluppo applicativo, sia come tecnico che come decision-maker.

Quali sono gli elementi dello sviluppo applicativo su cui incide il low-code?

Penso che non si possono valutare oggettivamente le novità introdotte dal low-code senza avere un quadro di riferimento che quello che è necessario allo sviluppo applicativo convenzionale.

Per questo, se non siete avvezzi con questo mondo, nelle seguenti sezioni descrivo un modello infrastrutturale ed un modello di architettura software che uso per inquadrare le piattaforme del low-code. 

Con un click sui seguenti titoli si possono vedere i modelli presi come base di partenza.

Lo stack infrastrutturale - un modello

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 

Lo stack infrastrutturale - come si è evoluto

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?

L'architettura del software (e altre riflessioni)

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.

Chi invece ha più esperienza, può saltare queste descrizioni perchè capirà benissimo i modelli usati. A quest’ultimi chiedo indulgenza consapevole. Ossia vi chiedo di non concentrarvi sulle carenze dei modelli proposti. Non sono modelli che devono guidare un team di sviluppo, sono dei recinti all’interno di quali collocare le nostre considerazioni per rendere confrontabili i variegati appartenenti al mondo del low-code. Nonostante le innovazioni apportate alle componenti infrastrutturali abbiano introdotto una maggiore flessibilità, queste non hanno influenzato in modo significativo le metodologie di sviluppo applicativo. Il beneficio di astrazione tra i vari livelli si limita sostanzialmente ai Sistemi Operativi. Non esiste, infatti, una virtualizzazione capace di farci prescindere dai vincoli e dai limiti inerenti allo sviluppo applicativo. La flessibilià dell’infrastruttura è stata utile ai team di sviluppo per rimuovere delle lentezze che gravavano sul processo di sviluppo ma non avevano nulla a che vedere con esso. La possibilità di clonare ambienti interi per farne degli ambienti di laboratorio su cui fare dei test, quella di stabilire un momento nel tempo dei propri sistemi (snapshot) e poter ritornare a quel momento, sono stati degli strumenti di efficienza formidabili per i team applicativi, ma non hanno modificato, di molto, il loro modo di sviluppare.

Qual è l’obiettivo delle piattaforme di low-code?

Sebbene ciascuna piattaforma abbia un approccio specifico, possiamo affermare, a rischio di suscitare il disappunto di programmatori esperti, che l’intento principale del low-code è il seguente:

Obiettivi del low-code

rendere le attività, di chi realizza le applicazioni,  focalizzate solo sulle finalità dell'applicazione stessa, eliminando di tutti gli sforzi e i tempi dovuti agli aspetti di tecnologia dell'ambiente in cui verrà eseguita l'applicazione.

Se questo alleggerimento-semplificazione viene attuata su tutti gli aspetti o solo su alcuni caratterizza e differenzia tra loro le piattaforme low-code. Ci sono piattaforme low-code che si occupano solamente della Business Logic, altre che affrontano solo aspetti di comunicazione tra differenti applicazioni. Il panorama dell’offerta low-code è vastissimo. 

Da evitare

Considerare il low-code come un semplice sostituto della programmazione, rifiutandolo od utilizzandolo come scorciatoia alla conoscenza dei linguaggi di programmazione.

Per capire quante e quali tipi di piattaforme low-code ci sono, un ottimo punto di partenza è il sito NoCodeJournal, nella loro pagina State of Nocode. Iniziato nel 2021, questo progetto cerca di elencare, ed aggiornare, tutte le piattaforme di low-code disponibili. È un compito impegnativo, perché il settore è in rapido movimento: nuove piattaforme nascono costantemente, mentre altre scompaiono altrettanto velocemente. Anche se non è aggiornatissimo, il sito dà un’idea dell’enorme varietà e del dinamismo di questo interessante settore tecnologico.

Come analizzare le piattaforme low-code

Oggi non parleremo delle migliori xx piattaforme low-code del 2023. Piuttosto, vediamo come analizzare alcune di queste piattaforme.

Le piattaforme che esamineremo non sono necessariamente le più popolari o le migliori in termini di velocità, facilità d’uso, ecc. Sono semplicemente quelle che ho avuto l’opportunità di testare personalmente per un periodo sufficiente a condurre un’analisi approfondita. Mi sono concentrato su piattaforme che offrono piani gratuiti o che mi hanno permesso di utilizzarle abbastanza a lungo per comprenderne le caratteristiche e le funzionalità.

Criteri di analisi

Esaminiamo ora i criteri per analizzare e valutare le piattaforme low-code, integrando i modelli già menzionati con altri fattori come il costo, il supporto, ecc. L’intento è definire un metodo di analisi che faciliti future valutazioni.

Ritengo che non si possa giudicare una piattaforma, o più genericamente un software, senza prima considerare il contesto specifico in cui verrà usata. Questo contesto include le esigenze da soddisfare, il tipo di utenti dell’applicazione e il budget a disposizione. Poiché il contesto può cambiare drasticamente, le classifiche generali su internet spesso non sono particolarmente utili per guidare la scelta.

Il modello proposto per l’analisi è il seguente:

le aree usate per l’analisi sono:

Funzionalità di sviluppo
  • Presentation Logic – funzionalità messe a disposizione per la realizzazione dell’interfaccia utente
  • Business Logic – funzionalità messe a disposizione per la realizzazione dei flussi di lavoro, dei controlli su operazioni e dati ed eventi
  • Data Logic – funzionalità messe a disposizione per la realizzazione delle strutture dati
  • Documentation – funzionalità messe a disposizione per descrivere e rendere comprensibile come è sviluppata l’applicazione e quali sono le sue dipendenze interne
Portabilità 
  • Data portability – funzionalità messe a disposizione per estrarre i dati dall’applicazione.
  • External integration – funzionalità messe a disposizione per la realizzazione di integrazioni con servizi o applicazioni esterne.
  • Infrastructure – tipologia di infrastruttura su cui può essere eseguita l’applicazione prodotta
Sicurezza
  • Security – funzionalità messe a disposizione per la realizzazione di meccanismi di sicurezza
  • Test and deployment – funzionalità messe a disposizione per i test e la gestione degli ambienti di produzione.
Altri servizi
  • Support – le modalità con cui si accede al supporto della piattaforma.
Costi
  • Price model – i meccanismi che influenzano il prezzo

 

Conclusioni

Con il modello così definito, non resta che metterlo alla prova. Quindi inizierò a valutare alcune piattaforme, ma la vera prova saranno i commenti e le critiche. Non tanto per vedere se va bene, quanto per indivuduare come è migliorabile.

Riferimenti utili per approfondire.

more insights